Modified computer architecture for a computer to operate in a multiple computer system

ABSTRACT

A modified computer architecture ( 50, 71, #1, #2, #3 ) which enables applications program ( 50 ) to be run simultaneously on a plurality of computers (M 1 , . . . Mn) and a computer for the multiple computer system are disclosed. Shared memory at each computer is updated with amendments and/or overwrites so memory read requests are satisfied locally. During initial program loading ( 75 ) instructions which result in memory being re-written/manipulated are identified. Instructions are inserted to cause equivalent memory locations at all computers to be updated. Initialization of JAVA language classes and objects is disclosed so memory locations for all computers are initialized in the same manner. Finalization of JAVA language classes and objects is disclosed. Finalization occurs when the last class/object on all machines is no longer required. During initial program loading ( 75 ) instructions which result in the program ( 50 ) acquiring/releasing a lock on an asset (synchronization) are identified. Instructions are inserted to result in a modified synchronization routine with which all computers are updated. A single computer arranged to operate in a multiple computer system is disclosed.

FIELD OF THE INVENTION

The present invention relates to computers and, in particular, to amodified machine architecture which enables the execution of differentportions of an application program written to operate only on a singlecomputer, substantially simultaneous on each of a plurality of computersinterconnected via a communications network.

BACKGROUND ART

Ever since the advent of computers, and computing, software forcomputers has been written to be operated upon a single machine. Asindicated in FIG. 1, that single prior art machine 1 is made up from acentral processing unit, or CPU, 2 which is connected to a memory 3 viaa bus 4. Also connected to the bus 4 are various other functional unitsof the single machine 1 such as a screen 5, keyboard 6 and mouse 7.

A fundamental limit to the performance of the machine 1 is that the datato be manipulated by the CPU 2, and the results of those manipulations,must be moved by the bus 4. The bus 4 suffers from a number of problemsincluding so called bus “queues” formed by units wishing to gain anaccess to the bus, conflict or −+contention problems, and the like.These problems can, to some extent, be alleviated by various stratagemsincluding cache memory, however, such stratagems invariably increase theadministrative overhead of the machine 1.

Naturally, over the years various attempts have been made to increasemachine performance. One approach is to use symmetric multipleprocessors. This prior art approach has been used in so called “super”computers and is schematically indicated in FIG. 2. Here a plurality ofCPU's 12 are connected to global memory 13. Again, a bottleneck arisesin the communications between the CPU's 12 and the memory 13. Thisprocess has been termed “Single System Image”. There is only oneapplication and one whole copy of the memory for the application whichis distributed over the global memory. The single application can readfrom and write to, (ie share) any memory location completelytransparently.

Where there are a number of such machines interconnected via a network,this is achieved by taking the single application written for a singlemachine and partitioning the required memory resources into parts. Theseparts are then distributed across a number of computers to form theglobal memory 13 accessible by all CPU's 12. This procedure relies onmasking, or hiding, the memory partition from the single runningapplication program. The performance degrades when one CPU on onemachine must access (via a network) a memory location physically locatedin a different machine.

Although super computers have been technically successful in achievinghigh computational rates, they are not commercially successful in thattheir inherent complexity makes them extremely expensive not only tomanufacture but to administer. In particular, the single system imageconcept has never been able to scale over “commodity” (or mass produced)computers and networks. Specifically, the Single System Image concepthas only found practical application on very fast (and hence veryexpensive) computers interconnected by very fast (and similarlyexpensive) networks.

A further possibility of increased computer power through the use of aplural number of machines arises from the prior art concept ofdistributed computing which is schematically illustrated in FIG. 3. Inthis known arrangement, a single application program (Ap) is partitionedby its author (or another programmer who has become familiar with theapplication program) into various discrete tasks so as to run upon, say,three machines in which case “n” in FIG. 3 is the integer 3. Theintention here is that each of the machines M1 . . . M3 runs a differentthird of the entire application and the intention is that the loadsapplied to the various machines be approximately equal. The machinescommunicate via a network 14 which can be provided in various forms suchas a communications link, the internet, intranets, local area networks,and the like. Typically the speed of operation of such networks 14 is anorder of magnitude slower than the speed of operation of the bus 4 ineach of the individual machines M1, M2, etc.

Distributed computing suffers from a number of disadvantages. Firstly,it is a difficult job to partition the application and this must be donemanually. Secondly, communicating data, partial results, results and thelike over the network 14 is an administrative overhead. Thirdly, theneed for partitioning makes it extremely difficult to scale upwardly byutilising more machines since the application having been partitionedinto, say three, does not run well upon four machines. Fourthly, in theevent that one of the machines should become disabled, the overallperformance of the entire system is substantially degraded.

A further prior art arrangement is known as network computing via“clusters” as is schematically illustrated in FIG. 4. In this approach,the entire application is loaded onto each of the machines M1, M2 . . .Mn. Each machine communicates with a common database but does notcommunicate directly with the other machines. Although each machine runsthe same application, each machine is doing a different “job” and usesonly its own memory. This is somewhat analogous to a number of windowseach of which sell train tickets to the public. This approach doesoperate, is scalable and mainly suffers from the disadvantage that it isdifficult to administer the network.

In computer languages such as for example JAVA and MICROSOFT.NET thereare two major types of constructs with which programmers deal. In theJAVA language these are known as objects and classes. More generallythey may be referred to as assets. Every time an object (or other asset)is created there is an initialization routine run known as an objectinitialization (e.g., “<init>”) routine. Similarly, every time a classis loaded there is a class initialization routine known as “<clinit>”.Other languages use different terms but utilize a similar concept. Ineither case, however, there is no equivalent “clean up” or deletionroutine to delete an object or class (or other asset) once it is nolonger required. Instead, this “clean up” happens unobtrusively in abackground mode.

Furthermore, in any computer environment it is necessary to acquire andrelease a lock to enable the use of such objects, classes, assets,resources or structures to avoid different parts of the applicationprogram from attempting to use the same objects, classes, assets,resources or structures at the one time. In the JAVA environment this isknown as synchronization. Synchronization more generally refers to theexclusive use of an object, class, resource, structure, or other assetto avoid contention between and among computers or machines. This isachieved in JAVA by the “monitor enter” and “monitor exit” instructionsor routines. Other languages use different terms but utilize a similarconcept.

Unfortunately, conventional computing systems, architectures, andoperating schemes do not provide for computing environments and methodsin which an application program can operate simultaneously on anarbitrary plurality of computers where the environment and operatingscheme ensure that the abovementioned memory management, initialization,clean up and synchronization procedures operate in a consistent andcoordinated fashion across all the computing machines.

The genesis of the present invention is a desire to provide a multiplecomputer system (and related arrangements such as individual computerswhich can operate in such a system, and a method of operating suchcomputers) which to some extent ameliorates the problems of prior artmultiple computer systems.

SUMMARY OF THE INVENTION

The present invention discloses a computing environment in which anapplication program operates simultaneously on a plurality of computers.In such an environment it is advantageous to ensure that theabovementioned asset initialization, clean-up and synchronizationprocedures operate in a consistent and coordinated fashion across allthe machines.

In accordance with a first aspect of the present invention there isdisclosed a single computer intended to operate in a multiple computersystem which comprises a plurality of computers each having a localmemory and each being interconnected via a communications network,wherein a different portion of at least one application program eachwritten to execute on only a single computer executes substantiallysimultaneously on a corresponding one of said plurality of computers,and at least one memory location is replicated in the local memory ofeach said computer, said single computer comprising:

a local memory having at least one memory location intended to beupdated via said communications network,a communications port for connection to said communications network, andupdating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s) whereby thecorresponding replicated memory location of each said computer of saidmultiple system can be updated via said communicating network and allsaid replicated memory locations can remain substantially identical.

In accordance with a second aspect of the present invention there isdisclosed a single computer intended to operate in a multiple computersystem which comprises a plurality of computers each having a localmemory and each being interconnected via a communications network,wherein a different portion of at least one application program eachwritten to execute on only a single computer executes substantiallysimultaneously on a corresponding one of said plurality of computers,and at least one memory location is replicated in the local memory ofeach said computer, said single computer comprising:

a local memory having at least one memory location intended to beupdated via said communications network,a communications port for connection to said communications network,updating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s), andinitialization means which determine the initial content or value ofsaid replicated memory location and which can be disabled.

In accordance with a third aspect of the present invention there isdisclosed a A single computer intended to operate in a multiple computersystem which comprises a plurality of computers each having a localmemory and each being interconnected via a communications network,wherein a different portion of at least one application program eachwritten to execute on only a single computer executes substantiallysimultaneously on a corresponding one of said plurality of computers,and at least one memory location is replicated in the local memory ofeach said computer, said single computer comprising:

a local memory having at least one memory location intended to beupdated via said communications network,a communications port for connection to said communications network,updating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s), andfinalization means which deletes said replicated memory location whenall said computers no longer need to refer thereto, said finalizationmeans being connected to said communications port to receive therefromdata transmitted over said network relating to continued reference ofother computers of said multiple computer system to said replicatedmemory location.

In accordance with a fourth aspect of the present invention there isdisclosed a A single computer intended to operate in a multiple computersystem which comprises a plurality of computers each having a localmemory and each being interconnected via a communications network,wherein a different portion of at least one application program eachwritten to execute on only a single computer executes substantiallysimultaneously on a corresponding one of said plurality of computers,and at least one memory location is replicated in the local memory ofeach said computer, said single computer comprising:

a local memory having at least one memory location intended to beupdated via said communications network,a communications port for connection to said communications network,updating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s), andlock acquisition and relinquishing means to respectively permit saidreplicated local memory location to be written to, and prevent saidreplicated local memory being written to, on command.

In accordance with a fifth aspect of the present invention there isdisclosed a single computer intended to operate in a multiple computersystem which comprises a plurality of computers each having a localmemory and each being interconnected via a communications network,wherein a different portion of at least one application program eachwritten to execute on only a single computer executes substantiallysimultaneously on a corresponding one of said plurality of computers,and at least one memory location is replicated in the local memory ofeach said computer, said single computer comprising:

a local memory having at least one memory location intended to beupdated via said communications network,a communications port for connection to said communications network,updating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s) whereby thecorresponding replicated memory location of each said computer of saidmultiple system can be updated via said communicating network and allsaid replicated memory locations can remain substantially identical,initialization means which determine the initial content or value ofsaid replicated memory location and which can be disabled,finalization means which deletes said replicated memory location whenall said computers no longer need to refer thereto, said finalizationmeans being connected to said communications port to receive therefromdata transmitted over said network relating to continued reference ofother computers of said multiple computer system to said replicatedmemory location, andlock acquisition and relinquishing means to respectively permit saidreplicated local memory location to be written to, and prevent saidreplicated local memory being written to, on command.

In accordance with a sixth aspect of the present invention there isdisclosed a multiple computer system having at least one applicationprogram each written to operate on only a single computer but runningsimultaneously on a plurality of computers interconnected by acommunications network, wherein different portions of said applicationprogram(s) execute substantially simultaneously on different ones ofsaid computers, wherein each computer has an independent local memoryaccessible only by the corresponding portion of said applicationprogram(s) and wherein for each said portion a like plurality ofsubstantially identical objects are created, each in the correspondingcomputer.

In accordance with a seventh aspect of the present invention there isdisclosed a plurality of computers interconnected via a communicationslink and each having an independent local memory and substantiallysimultaneously operating a different portion at least one applicationprogram each written to operate on only a single computer, each localmemory being accessible only by the corresponding portion of saidapplication program.

In accordance with a eighth aspect of the present invention there isdisclosed a multiple computer system having at least one applicationprogram each written to operate on only a single computer but runningsubstantially simultaneously on a plurality of computers interconnectedby a communications network, wherein different portions of saidapplication program(s) execute substantially simultaneously on differentones of said computers and for each said portion a like plurality ofsubstantially identical objects are created, each in the correspondingcomputer and each having a substantially identical name, and wherein theinitial contents of each of said identically named objects issubstantially the same.

In accordance with a ninth aspect of the present invention there isdisclosed a plurality of computers interconnected via a communicationslink and substantially simultaneously operating at least one applicationprogram each written to operation on only a single computer wherein eachsaid computer substantially simultaneously executes a different portionof said application program(s), each said computer in operating itsapplication program portion creates objects only in local memoryphysically located in each said computer, the contents of the localmemory utilized by each said computer are fundamentally similar but not,at each instant, identical, and every one of said computers hasdistribution update means to distribute to all other said computersobjects created by said one computer.

In accordance with a tenth aspect of the present invention there isdisclosed a multiple computer system having at least one applicationprogram each written to operate only on a single computer but runningsubstantially simultaneously on a plurality of computers interconnectedby a communications network, wherein different portions of saidapplication program(s) execute substantially simultaneously on differentones of said computers and for each said portion a like plurality ofsubstantially identical objects are created, each in the correspondingcomputer and each having a substantially identical name, and wherein allsaid identical objects are collectively deleted when each one of saidplurality of computers no longer needs to refer to their correspondingobject.

In accordance with an eleventh aspect of the present invention there isdisclosed a plurality of computers interconnected via a communicationslink and operating substantially simultaneously at least one applicationprogram each written to operate only on a single computer, wherein eachsaid computer substantially simultaneously executes a different portionof said application program(s), each said computer in operating itsapplication program portion needs, or no longer needs to refer to anobject only in local memory physically located in each said computer,the contents of the local memory utilized by each said computer isfundamentally similar but not, at each instant, identical, and every oneof said computers has a finalization routine which deletes anon-referenced object only if each one of said plurality of computers nolonger needs to refer to their corresponding object.

In accordance with a twelfth aspect of the present invention there isdisclosed a multiple computer system having at least one applicationprogram each written to operate on only a single computer but runningsubstantially simultaneously on a plurality of computers interconnectedby a communications network, wherein different portions of saidapplication program(s) execute substantially simultaneously on differentones of said computers and for each portion a like plurality ofsubstantially identical objects are created, each in the correspondingcomputer and each having a substantially identical name, and said systemincluding a lock means applicable to all said computers wherein anycomputer wishing to utilize a named object therein acquires anauthorizing lock from said lock means which permits said utilization andwhich prevents all the other computers from utilizing theircorresponding named object until said authorizing lock is relinquished.

In accordance with a thirteenth aspect of the present invention there isdisclosed a plurality of computers interconnected via a communicationslink and operating substantially simultaneously at least one applicationprogram each written to operate on only a single computer, wherein eachsaid computer substantially simultaneously executes a different portionof said application program(s), each said computer in operating itsapplication program portion utilizes an object only in local memoryphysically located in each said computer, the contents of the localmemory utilized by each said computer is fundamentally similar but not,at each instant, identical, and every one of said computers has anacquire lock routine and a release lock routine which permit utilizationof the local object only by one computer and each of the remainder ofsaid plurality of computers is locked out of utilization of theircorresponding object.

In accordance with a fourteenth aspect of the present invention there isdisclosed a method of running simultaneously on a plurality of computersat least one application program each written to operate on only asingle computer, said computers being interconnected by means of acommunications network, said method comprising the step of,

(i) executing different portions of said application program(s) ondifferent ones of said computers and for each said portion creating alike plurality of substantially identical objects each in thecorresponding computer and each accessible only by the correspondingportion of said application program.

In accordance with a fifteenth aspect of the present invention there isdisclosed a method of loading an application program written to operateonly on a single computer onto each of a plurality of computers, thecomputers being interconnected via a communications link, and differentportions of said application program(s) being substantiallysimultaneously executable on different computers with each computerhaving an independent local memory accessible only by the correspondingportion of said application program(s), the method comprising the stepof modifying the application before, during, or after loading and beforeexecution of the relevant portion of the application program.

In accordance with a sixteenth aspect of the present invention there isdisclosed a method of operating simultaneously on a plurality ofcomputers all interconnected via a communications link at least oneapplication program each written to operate on only a single computer,each of said computers having at least a minimum predetermined localmemory capacity, different portions of said application program(s) beingsubstantially simultaneously executed on different ones of saidcomputers with the local memory of each computer being only accessibleby the corresponding portion of said application program(s), said methodcomprising the steps of:

(i) initially providing each local memory in substantially identicalcondition,(ii) satisfying all memory reads and writes generated by each saidapplication program portion from said corresponding local memory, and(iii) communicating via said communications link all said memory writesat each said computer which take place locally to all the remainder ofsaid plurality of computers whereby the contents of the local memoryutilised by each said computer, subject to an updating data transmissiondelay, remains substantially identical.

In accordance with a seventeenth aspect of the present invention thereis disclosed a method of compiling or modifying an application programwritten to operate on only a single computer but to run simultaneouslyon a plurality of computers interconnected via a communications link,with different portions of said application program(s) executingsubstantially simultaneously on different ones of said computers each ofwhich has an independent local memory accessible only by thecorresponding portion of said application program, said methodcomprising the steps of:

(i) detecting instructions which share memory records utilizing one ofsaid computers,(ii) listing all such shared memory records and providing a naming tagfor each listed memory record,(iii) detecting those instructions which write to, or manipulate thecontents of, any of said listed memory records, and(iv) activating an updating propagation routine following each saiddetected write or manipulate instruction, said updating propagationroutine forwarding the re-written or manipulated contents and name tagof each said re-written or manipulated listed memory record to theremainder of said computers.

In accordance with an eighteenth aspect of the present invention thereis disclosed a multiple thread processing computer operation in whichindividual threads of a single application program written to operate ononly a single computer are simultaneously being processed each on adifferent corresponding one of a plurality of computers each having anindependent local memory accessible only by the corresponding thread andeach being interconnected via a communications link, the improvementcomprising communicating changes in the contents of local memoryphysically associated with the computer processing each thread to thelocal memory of each other said computer via said communications link.

In accordance with a nineteenth aspect of the present invention there isdisclosed a method of running substantially simultaneously on aplurality of computers at least one application program each written tooperate on only a single computer, said computers being interconnectedby means of a communications network, said method comprising the stepsof:

(i) executing different portions of said application program(s) ondifferent ones of said computers and for each said portion creating alike plurality of substantially identical objects each in thecorresponding computer and each having a substantially identical name,and(ii) creating the initial contents of each of said identically namedobjects substantially the same.

In accordance with a twentieth aspect of the present invention there isdisclosed a method of compiling or modifying an application programwritten to operate on only a single computer to have different portionsthereof to execute substantially simultaneously on different ones of aplurality of computers interconnected via a communications link, saidmethod comprising the steps of:

(i) detecting instructions which create objects utilizing one of saidcomputers,(ii) activating an initialization routine following each said detectedobject creation instruction, said initialization routine forwarding eachcreated object to the remainder of said computers.

In accordance with a twenty first aspect of the present invention thereis disclosed a multiple thread processing computer operation in whichindividual threads of a single application program written to operate ononly a single computer are substantially simultaneously being processedeach on a different corresponding one of a plurality of computersinterconnected via a communications link, the improvement comprisingcommunicating objects created in local memory physically associated withthe computer processing each thread to the local memory of each othersaid computer via said communications link.

In accordance with a twenty second aspect of the present invention thereis disclosed a method of ensuring consistent initialization of anapplication program written to operate on only a single computer butdifferent portions of which are to be executed substantiallysimultaneously each on a different one of a plurality of computersinterconnected via a communications network, said method comprising thesteps of:

(i) scrutinizing said application program at, or prior to, or afterloading to detect each program step defining an initialization routine,and(ii) modifying said initialization routine to ensure consistentoperation of all said computers.

In accordance with a twenty third aspect of the present invention thereis disclosed a method of running substantially simultaneously on aplurality of computers at least one application program each written tooperate only on a single computer, said computers being interconnectedby means of a communications network, said method comprising the stepsof:

(i) executing different portions of said application program(s) ondifferent ones of said computers and for each said portion creating alike plurality of substantially identical objects each in thecorresponding computer and each having a substantially identical name,and(ii) deleting all said identical objects collectively when all of saidplurality of computers no longer need to refer to their correspondingobject.

In accordance with a twenty fourth aspect of the present invention thereis disclosed a method of ensuring consistent finalization of anapplication program written to operate only on a single computer butdifferent portions of which are to be executed substantiallysimultaneously each on a different one of a plurality of computersinterconnected via a communications network, said method comprising thesteps of:

(i) scrutinizing said application program at, or prior to, or afterloading to detect each program step defining an finalization routine,and(ii) modifying said finalization routine to ensure collective deletionof corresponding objects in all said computers only when each one ofsaid computers no longer needs to refer to their corresponding object.

In accordance with a twenty fifth aspect of the present invention thereis disclosed a multiple thread processing computer operation in whichindividual threads of a single application program written to operateonly on a single computer are substantially simultaneously beingprocessed each on a corresponding different one of a plurality ofcomputers interconnected via a communications link, and in which objectsin local memory physically associated with the computer processing eachthread have corresponding objects in the local memory of each other saidcomputer, the improvement comprising collectively deleting all saidcorresponding objects when each one of said plurality of computers nolonger needs to refer to their corresponding object.

In accordance with a twenty sixth aspect of the present invention thereis disclosed a method of running substantially simultaneously on aplurality of computers at least one application program each written tooperate only on a single computer, said computers being interconnectedby means of a communications network, said method comprising the stepsof:

(i) executing different portions of said application program(s) ondifferent ones of said computers and for each said portion creating alike plurality of substantially identical objects each in thecorresponding computer and each having a substantially identical name,and(ii) requiring any of said computers wishing to utilize a named objecttherein to acquire an authorizing lock which permits said utilizationand which prevents all the other computers from utilizing theircorresponding named object until said authorizing lock is relinquished.

In accordance with a twenty seventh aspect of the present inventionthere is disclosed a method of ensuring consistent synchronization of anapplication program written to operate only on a single computer butdifferent portions of which are to be executed substantiallysimultaneously each on a different one of a plurality of computersinterconnected via a communications network, said method comprising thesteps of:

(i) scrutinizing said application program at, or prior to, or afterloading to detect each program step defining an synchronization routine,and(ii) modifying said synchronization routine to ensure utilization of anobject by only one computer and preventing all the remaining computersfrom simultaneously utilizing their corresponding objects.

In accordance with a twenty eighth aspect of the present invention thereis disclosed a multiple thread processing computer operation in whichindividual threads of a single application program written to operateonly on a single computer are substantially simultaneously beingprocessed each on a corresponding different one of a plurality ofcomputers interconnected via a communications link, and in which objectsin local memory physically associated with the computer processing eachthread have corresponding objects in the local memory of each other saidcomputer, the improvement comprising permitting only one of saidcomputers to utilize an object and preventing all the remainingcomputers from simultaneously utilizing their corresponding object.

In accordance with a twenty ninth aspect of the present invention thereis disclosed a computer program product comprising a set of programinstructions stored in a storage medium and operable to permit one or aplurality of computers to carry out the abovementioned methods.

In accordance with a thirtieth aspect of the invention there isdisclosed a distributed run time and distributed run time system adaptedto enable communications between a plurality of computers, computingmachines, or information appliances.

In accordance with a thirty first aspect of the invention there isdisclosed a modifier, modifier means, and modifier routine for modifyingan application program written to execute on a single computer orcomputing machine whereby the modified application program executessubstantially simultaneously on a plurality of networked computers orcomputing machines.

In accordance with a thirty second aspect of the present invention thereis disclosed a computer program and computer program product written tooperate on only a single computer but product comprising a set ofprogram instructions stored in a storage medium and operable to permit aplurality of computers to carry out the above-mentioned procedures,routines, and methods.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described withreference to the drawings in which:

FIG. 1 is a schematic view of the internal architecture of aconventional computer,

FIG. 2 is a schematic illustration showing the internal architecture ofknown symmetric multiple processors,

FIG. 3 is a schematic representation of prior art distributed computing,

FIG. 4 is a schematic representation of a prior art network computingusing clusters,

FIG. 5 is a schematic block diagram of a plurality of machines operatingthe same application program in accordance with a first embodiment ofthe present invention,

FIG. 6 is a schematic illustration of a prior art computer arranged tooperate JAVA code and thereby constitute a JAVA virtual machine,

FIG. 7 is a drawing similar to FIG. 6 but illustrating the initialloading of code in accordance with the preferred embodiment,

FIG. 8 is a drawing similar to FIG. 5 but illustrating theinterconnection of a plurality of computers each operating JAVA code inthe manner illustrated in FIG. 7,

FIG. 9 is a flow chart of the procedure followed during loading of thesame application on each machine in the network,

FIG. 10 is a flow chart showing a modified procedure similar to that ofFIG. 9,

FIG. 11 is a schematic representation of multiple thread processingcarried out on the machines of FIG. 8 utilizing a first embodiment ofmemory updating,

FIG. 12 is a schematic representation similar to FIG. 11 butillustrating an alternative embodiment,

FIG. 13 illustrates multi-thread memory updating for the computers ofFIG. 8,

FIG. 14 is a schematic illustration of a prior art computer arranged tooperate in JAVA code and thereby constitute a JAVA virtual machine,

FIG. 15 is a schematic representation of n machines running theapplication program and serviced by an additional server machine X,

FIG. 16 is a flow chart of illustrating the modification ofinitialization routines,

FIG. 17 is a flow chart illustrating the continuation or abortion ofinitialization routines,

FIG. 18 is a flow chart illustrating the enquiry sent to the servermachine X,

FIG. 19 is a flow chart of the response of the server machine X to therequest of FIG. 18,

FIG. 20 is a flowchart illustrating a modified initialization routinefor the <clinit> instruction,

FIG. 21 is a flowchart illustrating a modified initialization routinefor the <init> instruction,

FIG. 22 is a flow chart of illustrating the modification of “clean up”or finalization routines,

FIG. 23 is a flow chart illustrating the continuation or abortion offinalization routines,

FIG. 24 is a flow chart illustrating the enquiry sent to the servermachine X,

FIG. 25 is a flow chart of the response of the server machine X to therequest of FIG. 24,

FIG. 26 is a flow chart of illustrating the modification of the monitorenter and exit routines,

FIG. 27 is a flow chart illustrating the process followed by processingmachine in requesting the acquisition of a lock,

FIG. 28 is a flow chart illustrating the requesting of the release of alock,

FIG. 29 is a flow chart of the response of the server machine X to therequest of FIG. 27,

FIG. 30 is a flow chart illustrating the response of the server machineX to the request of FIG. 28,

FIG. 31 is a schematic representation of two laptop computersinterconnected to simultaneously run a plurality of applications, withboth applications running on a single computer,

FIG. 32 is a view similar to FIG. 31 but showing the FIG. 31 apparatuswith one application operating on each computer, and

FIG. 33 is a view similar to FIGS. 31 and 32 but showing the FIG. 31apparatus with both applications operating simultaneously on bothcomputers.

REFERENCE TO ANNEXES

Although the specification provides a complete and detailed descriptionof the several embodiments of the invention such that the invention maybe understood and implemented without reference to other materials, thespecification does includes Annexures A, B, C and D which provideexemplary actual program or code fragments which implement variousaspects of the described embodiments. Although aspects of the inventionare described throughout the specification including the Annexes,drawings, and claims, it may be appreciated that Annexure A relatesprimarily to fields, Annexure B relates primarily to initialization,Annexure C relates primarily to finalization, and Annexure D relatesprimarily to synchronization. More particularly, the accompanyingAnnexures are provided in which:

Annexures A1-A10 illustrate exemplary code to illustrate embodiments ofthe invention in relation to fields.

Annexure B1 is an exemplary typical code fragment from an unmodifiedclass initialization <clinit> instruction, Annexure B2 is an equivalentin respect of a modified class initialization <clinit> instruction.Annexure B3 is a typical code fragment from an unmodified objectinitialization <init> instruction. Annexure B4 is an equivalent inrespect of a modified object initialization <init> instruction. Inaddition, Annexure B5 is an alternative to the code of Annexure B2 foran unmodified class initialization instruction, and Annexure B6 is analternative to the code of Annexure B4 for a modified objectinitialization <init> instruction. Furthermore, Annexure B7 is exemplarycomputer program source-code of InitClient, which queries an“initialization server” for the initialization status of the relevantclass or object. Annexure B8 is the computer program source-code ofInitServer, which receives an initialization status query by InitClientand in response returns the corresponding status. Similarly, Annexure B9is the computer program source-code of the example application used inthe before/after examples of Annexure B1-B6.

It will be appreciated in light of the description provided here thatthe categorization of the Annexures as well as the use of other headingsand subheadings in this description is intended as an aid to the readerand is not to be used to limit the scope of the invention in any way.

DETAILED DESCRIPTION

The present invention discloses a modified computer architecture whichenables an applications program to be run simultaneously on a pluralityof computers in a manner that overcomes the limitations of theaforedescribed conventional architectures, systems, methods, andcomputer programs.

In one aspect, shared memory at each computer may be updated withamendments and/or overwrites so that all memory read requests aresatisfied locally. Before, during or after program loading, but beforeexecution of relevant portions of the program code are executed, orsimilar, instructions which result in memory being re-written ormanipulated are identified. Additional instructions are inserted intothe program code (or other modification made) to cause the equivalentmemory locations at all computers to be updated. While the invention isnot limited to JAVA language or virtual machines, exemplary embodimentsare described relative to the JAVA language and standards. In anotheraspect, the initialization of JAVA language classes and objects (orother assets) are provided for so all memory locations for all computersare initialized in the same manner. In another aspect, the finalizationof JAVA language classes and objects is also provide so finalizationonly occurs when the last class or object present on all machines is nolonger required. In still another aspect, synchronization is providedsuch that instructions which result in the application program acquiring(or releasing) a lock on a particular asset (synchronization) areidentified. Additional instructions are inserted (or other codemodifications performed) to result in a modified synchronization routinewith which all computers are updated.

The present invention also discloses a computing environment andcomputing method in which an application program operates simultaneouslyon a plurality of computers. In such an environment it is advantageousto ensure that the above-mentioned initialization, clean-up andsynchronization procedures operate in a consistent and coordinatedfashion across all the machines. These memory replication, object orother asset initialization, finalization, and synchronization may beused and applied separately in a variety of computing and informationprocessing environments. Furthermore, they may advantageously beimplemented and applied in any combination so as to provide synergisticeffects for multi-computer processing, such as network based distributedcomputing.

As each of the architectural, system, procedural, method and computerprogram aspects of the invention (e.g., memory management andreplication, initialization, finalization, and synchronization) may beapplied separately, they are thus first described without specificreference to the other aspects. It will however be appreciated in lightof the descriptions provided that the object, class, or other assetcreation or initialization may generally precede finalization of suchobjects, classes, or other assets.

In addition, during the loading of, or at any time preceding theexecution of, the application code 50 (or relevant portion thereof) oneach machine M1, M2 . . . Mn, each application code 50 has been modifiedby the corresponding modifier 51 according to the same rules (orsubstantially the same rules since minor optimizing changes arepermitted within each modifier 51/1, 51/2, . . . , 51/n). Where separatemodifications are required on any particular machine, such as to machineM2, to effect the memory management, initialization, finalization,and/or synchronization for that machine, then each machine may in facthave and be modified according to a plurality of separate modifiers(such as 51/2-M (e.g., M2 memory management modifier), 51/2-I (e.g., M2initialization modifier), 51/2-F (e.g., M2 finalization modifier),and/or 51/2-S (e.g., M2 synchronization modifier); or alternatively anyone or more of these modifiers may be combined into a combined modifierfor that computer or machine. In at least some embodiments, efficiencieswill result from performing the steps required to identify themodification required, in performing the actual modification, and incoordinating the operation of the plurality or constellation ofcomputers or machines in an organized, consistent, and coherent manner.These modifications may be performed in accordance with aspects of theinvention by the distributed run time means 71 described in greaterdetail hereinafter. In analogous manner those workers having ordinaryskill in the art in light of the description provided herein willappreciate that the structural and methodological aspects of thedistributed run time, distributed run time system, and distributed runtime means as they are described herein specifically to memorymanagement, initialization, finalization, and/or synchronization may becombined so any of the modifications required to an application programor code may be made separately or in combination to achieve any requiredmemory management, initialization, finalization, and/or synchronizationon any particular machine and across the plurality of machines M1, M2, .. . , Mn.

With specific reference to any memory management modifier that may beprovided, such memory management modifier 51-M or DRT 71-M or other codemodifying means component of the overall modifier or distributed runtime means is responsible for creating or replicating a memory structureand contents on each of the individual machines M1, M2 . . . Mn thatpermits the plurality of machines to interoperate. In some embodimentsthis replicated memory structure will be identical, in other embodimentsthis memory structure will have portions that are identical and otherportions that are not, and in still other embodiments the memorystructures are or may not be identical.

With reference to any initialisation modifier that may be present, suchinitialisation modifier 51-I or DRT 71-I or other code modifying meanscomponent of the overall modifier or distributed run time means isresponsible for modifying the application code 50 so that it may executeinitialisation routines or other initialization operations, such as forexample class and object initialization methods or routines in the JAVAlanguage and virtual machine environment, in a coordinated, coherent,and consistent manner across the plurality of individual machines M1, M2. . . Mn.

With reference to the finalization modifier that may be present, suchfinalization modifier 51-F or DRT 71-F or other code modifying means isresponsible for modifying the application code 50 so that the code mayexecute finalization clean-up, or other memory reclamation, recycling,deletion or finalization operations, such as for example finalizationmethods in the JAVA language and virtual machine environment, in acoordinated, coherent and consistent manner across the plurality ofindividual machines M1, M2, . . . , Mn.

Furthermore, with reference to any synchronization modifier that may bepresent, such synchronization modifier 51-S or DRT 71-S or other codemodifying means is responsible for ensuring that when a part (such as athread or process) of the modified application program 50 running on oneor more of the machines exclusively utilizes (e.g., by means of asynchronization routine or similar or equivalent mutual exclusionoperator or operation) a particular local asset, such as an objects50X-50Z or class 50A, no other different and potentially concurrentlyexecuting part on machines M2 . . . Mn exclusively utilizes the similarequivalent corresponding asset in its local memory at once or at thesame time.

These structures and procedures when applied in combination whenrequired, maintain a computing environment where memory locations,address ranges, objects, classes, assets, resources, or any otherprocedural or structural aspect of a computer or computing environmentare where required created, maintained, operated, and deactivated ordeleted in a coordinated, coherent, and consistent manner across theplurality of individual machines M1, M2 . . . Mn.

The embodiments will be described with reference to the JAVA language,however, it will be apparent to those skilled in the art that theinvention is not limited to this language and, in particular can be usedwith the similar languages (including procedural, declarative and objectoriented languages) including the MICROSOFT.NET platform andarchitecture (Visual Basic, Visual C, and Visual C++, and Visual C#),FORTRAN, C, C++, COBOL, BASIC and the like.

In connection with FIG. 5, in accordance with a preferred embodiment ofthe present invention a single application program 50 can be operatedsimultaneously on a number of computers or machines M1, M2 . . . Mncommunicating via network 53. As it will become apparent hereafter, eachof the machines M1, M2 . . . Mn operates with the same applicationprogram 50 on each machine M1, M2 . . . Mn and thus all of the machinesM1, M2 . . . Mn have the same, or substantially the same, applicationcode and data 50. Similarly, each of the machines M1, M2 . . . Mnoperates with the same (or substantially the same) modifier 51 on eachmachine M1, M2 . . . Mn and thus all of the machines M1, M2 . . . Mnhave the same (or substantially the same) modifier 51 with the modifierof machine M2 being designated 51/2. In addition, during the loading of,or preceding the execution of, the application 50 on each machine M1, M2. . . Mn, each application 50 has been modified by the correspondingmodifier 51 according to the same rules (or substantially the same rulessince minor optimising changes are permitted within each modifier 51/1 .. . 51/n).

As a consequence of the above described arrangement, if each of themachines M1, M2 . . . Mn has, say, a shared memory capability of 10 MB,then the total shared memory available to each application 50 is not, asone might expect, 10 n MB. However, how this results in improvedoperation will become apparent hereafter. Naturally, each machine M1, M2. . . Mn has an unshared memory capability. The unshared memorycapability of the machines M1, M2 . . . Mn are normally approximatelyequal but need not be.

It is known in the prior art to provide a single computer or machine(produced by any one of various manufacturers and having an operatingsystem operating in any one of various different languages) utilizingthe particular language of the application by creating a virtual machineas illustrated in FIG. 6.

The code and data and virtual machine configuration or arrangement ofFIG. 6 takes the form of the application code 50 written in the JAVAlanguage and executing within the JAVA virtual machine 61. Thus wherethe intended language of the application is the language JAVA, a JAVAvirtual machine is used which is able to operate code in JAVAirrespective of the machine manufacturer and internal details of thecomputer or machine.

For further details, see “The JAVA Virtual Machine Specification” 2^(nd)Edition by T. Lindholm and F. Yellin of Sun Microsystems Inc of the USAwhich is incorporated by reference herein.

This conventional art arrangement of FIG. 6 is modified in accordancewith embodiments of the present invention by the provision of anadditional facility which is conveniently termed a “distributed runtime” or a “distributed run time system” DRT 71 and as seen in FIG. 7.

In FIGS. 7 and 8, the application code 50 is loaded onto the JavaVirtual Machine(s) M1, M2, . . . Mn in cooperation with the distributedruntime system 71, through the loading procedure indicated by arrow 75or 75A or 75B. As used herein the terms “distributed runtime” and the“distributed run time system” are essentially synonymous, and by meansof illustration but not limitation are generally understood to includelibrary code and processes which support software written in aparticular language running on a particular platform. Additionally, adistributed runtime system may also include library code and processeswhich support software written in a particular language running within aparticular distributed computing environment. The runtime systemtypically deals with the details of the interface between the programand the operating system such as system calls, program start-up andtermination, and memory management. For purposes of background, aconventional Distributed Computing Environment (DCE) (that does notprovide the capabilities of the inventive distributed run time ordistributed run time system 71 used in the preferred embodiments of thepresent invention) is available from the Open Software Foundation. ThisDistributed Computing Environment (DCE) performs a form ofcomputer-to-computer communication for software running on the machines,but among its many limitations, it is not able to implement the desiredmodification or communication operations. Among its functions andoperations the preferred DRT 71 coordinates the particularcommunications between the plurality of machines M1, M2, . . . Mn.Moreover, the preferred distributed runtime 71 comes into operationduring the loading procedure indicated by arrow 75A or 75B of the JAVAapplication 50 on each JAVA virtual machine 72 or machines JVM#1,JVKMJ#2, . . . JVM#n of FIG. 8. It will be appreciated in light of thedescription provided herein that although many examples and descriptionsare provided relative to the JAVA language and JAVA virtual machines sothat the reader may get the benefit of specific examples, the inventionis not restricted to either the JAVA language or JAVA virtual machines,or to any other language, virtual machine, machine or operatingenvironment.

FIG. 8 shows in modified form the arrangement of the JAVA virtualmachines, each as illustrated in FIG. 7. It will be apparent that againthe same application code 50 is loaded onto each machine M1, M2 . . .Mn. However, the communications between each machine M1, M2 . . . Mn areas indicated by arrows 83, and although physically routed through themachine hardware, are advantageously controlled by the individual DRT's71/1 . . . 71/n within each machine. Thus, in practice this may beconceptionalised as the DRT's 71/1, . . . 71/n communicating with eachother via the network or other communications link 53 rather than themachines M1, M2 . . . Mn communicating directly themselves or with eachother. Contemplated and included are either this direct communicationbetween machines M1, M2 . . . Mn or DRT's 71/1, 71/2 . . . 71/n or acombination of such communications. The preferred DRT 71 providescommunication that is transport, protocol, and link independent.

The one common application program or application code 50 and itsexecutable version (with likely modification) is simultaneously orconcurrently executing across the plurality of computers or machines M1,M2 . . . Mn. The common application program 5. The application program 5is written with the intention that it only operate on a single machineor computer. Essentially the modified structure is to replicate andidentical memory structure and contents on each of the individualmachines

The term common application program is to be understood to mean anapplication program or application program code written to operate on asingle machine, and loaded and/or executed in whole or in part on eachone of the plurality of computers or machines M1, M2 . . . Mn, oroptionally on each one of some subset of the plurality of computers ormachines M1, M2 . . . Mn. Put somewhat differently, there is a commonapplication program represented in application code 50. This is either asingle copy or a plurality of identical copies each individuallymodified to generate a modified copy or version of the applicationprogram or program code. Each copy or instance is then prepared forexecution on the corresponding machine. At the point after they aremodified they are common in the sense that they perform similaroperations and operate consistently and coherently with each other. Itwill be appreciated that a plurality of computers, machines, informationappliances, or the like implementing embodiments of the invention mayoptionally be connected to or coupled with other computers, machines,information appliances, or the like that do not implement embodiments ofthe invention.

The same application program 50 (such as for example a parallel mergesort, or a computational fluid dynamics application or a data miningapplication) is run on each machine, but the executable code of thatapplication program is modified on each machine as necessary such thateach executing instance (copy or replica) on each machine coordinatesits local operations on that particular machine with the operations ofthe respective instances (or copies or replicas) on the other machinessuch that they function together in a consistent, coherent andcoordinated manner and give the appearance of being one global instanceof the application (i.e. a “meta-application”).

The copies or replicas of the same or substantially the same applicationcodes, are each loaded onto a corresponding one of the interoperatingand connected machines or computers. As the characteristics of eachmachine or computer may differ, the application code 50 may be modifiedbefore loading, during the loading process, and with some disadvantagesafter the loading process, to provide a customization or modification ofthe code on each machine. Some dissimilarity between the programs may bepermitted so long as the other requirements for interoperability,consistency, and coherency as described herein can be maintained. As itwill become apparent hereafter, each of the machines M1, M2 . . . Mn andthus all of the machines M1, M2 . . . Mn have the same or substantiallythe same application code 50, usually with a modification that may bemachine specific.

Before the loading of, during the loading of, or at any time precedingthe execution of, the application code 50 (or the relevant portionthereof) on each machine M1, M2 . . . Mn, each application code 50 ismodified by a corresponding modifier 51 according to the same rules (orsubstantially the same rules since minor optimizing changes arepermitted within each modifier 51/1, 51/2 . . . 51/n).

Each of the machines M1, M2 . . . Mn operates with the same (orsubstantially the same or similar) modifier 51 (in some embodimentsimplemented as a distributed run time or DRT 71 and in other embodimentsimplemented as an adjunct to the code and data 50, and also able to beimplemented either to the JAVA virtual machine itself). Thus all of themachines M1, M2 . . . Mn have the same (or substantially the same orsimilar) modifier 51 for each modification required. A differentmodification, for example, may be required for memory management andreplication, for initialization, for finalization, and/or forsynchronization (though not all of these modification types may berequired for all embodiments).

There are alternative implementations of the modifier 51 and thedistributed run time 71. For example as indicated by broken lines inFIG. 8, the modifier 51 may be implemented as a component of or withinthe distributed run time 71, and therefore the DRT 71 may implement thefunctions and operations of the modifier 51. Alternatively, the functionand operation of the modifier 51 may be implemented outside of thestructure, software, firmware, or other means used to implement the DRT71 such as within the code and data 50, or within the JAVA virtualmachine itself. In one embodiment, both the modifier 51 and DRT 71 areimplemented or written in a single piece of computer program code thatprovides the functions of the DRT and modifier. In this case themodifier function and structure is, in practice, subsumed into the DRT.Independent of how it is implemented, the modifier function andstructure is responsible for modifying the executable code of theapplication code program, and the distributed run time function andstructure is responsible for implementing communications between andamong the computers or machines. The communications functionality in oneembodiment is implemented via an intermediary protocol layer within thecomputer program code of the DRT on each machine. The DRT can, forexample, implement a communications stack in the JAVA language and usethe Transmission Control Protocol/Internet Protocol (TCP/IP) to providefor communications or talking between the machines. Exactly how thesefunctions or operations are implemented or divided between structuraland/or procedural elements, or between computer program code or datastructures, is not crucial.

However, in the arrangement illustrated in FIG. 8, a plurality ofindividual computers or machines M1, M2 . . . Mn are provided, each ofwhich are interconnected via a communications network 53 or othercommunications link. Each individual computer or machine is providedwith a corresponding modifier 51. Each individual computer is alsoprovided with a communications port which connects to the communicationsnetwork. The communications network 53 or path can be any electronicsignalling, data, or digital communications network or path and ispreferably slow speed, and thus low cost, communications path, such as anetwork connection over the Internet or any common networkingconfigurations including communication ports known or available as ofthe date of this application such as ETHERNET or INFINIBAND andextensions and improvements, thereto.

As a consequence of the above described arrangement, if each of themachines M1, M2, . . . , Mn has say an internal or local memorycapability of 10 MB, then the total memory available to the applicationcode 50 in its entirety is not, as one might expect, the number ofmachines (n) times 10 MB. Nor is it the additive combination of theinternal memory capability of all n machines. Instead it is either 10MB, or some number greater than 10 MB but less than n×10 MB. In thesituation where the internal memory capacities of the machines aredifferent, which is permissible, then in the case where the internalmemory in one machine is smaller than the internal memory capability ofat least one other of the machines, then the size of the smallest memoryof any of the machines may be used as the maximum memory capacity of themachines when such memory (or a portion thereof) is to be treated as‘common’ memory (i.e. similar equivalent memory on each of the machinesM1 . . . Mn) or otherwise used to execute the common application code.

However, even though the manner that the internal memory of each machineis treated may initially appear to be a possible constraint onperformance, how this results in improved operation and performance willbecome apparent hereafter. Naturally, each machine M1, M2 . . . Mn has aprivate (i.e. ‘non-common’) internal memory capability. The privateinternal memory capability of the machines M1, M2, . . . , Mn arenormally approximately equal but need not be. It may also beadvantageous to select the amounts of internal memory in each machine toachieve a desired performance level in each machine and across aconstellation or network of connected or coupled plurality of machines,computers, or information appliances M1, M2, . . . , Mn. Havingdescribed these internal and common memory considerations, it will beapparent in light of the description provided herein that the amount ofmemory that can be common between machines is not a limitation.

In some embodiments, some or all of the plurality of individualcomputers or machines can be contained within a single housing orchassis (such as so-called “blade servers” manufactured byHewlett-Packard Development Company, Intel Corporation, IBM Corporationand others) or implemented on a single printed circuit board or evenwithin a single chip or chip set.

When implemented in a non-JAVA language or application code environment,the generalized platform, and/or virtual machine and/or machine and/orruntime system is able to operate application code 50 in the language(s)(possibly including for example, but not limited to any one or more ofsource-code languages, intermediate-code languages, object-codelanguages, machine-code languages, and any other code languages) of thatplatform and/or virtual machine and/or machine and/or runtime systemenvironment, and utilize the platform, and/or virtual machine and/ormachine and/or runtime system and/or language architecture irrespectiveof the machine manufacturer and the internal details of the machine. Itwill also be appreciated that the platform and/or runtime system caninclude virtual machine and non-virtual machine software and/or firmwarearchitectures, as well as hardware and direct hardware codedapplications and implementations.

For a more general set of virtual machine or abstract machineenvironments, and for current and future computers and/or computingmachines and/or information appliances or processing systems, and thatmay not utilize or require utilization of either classes and/or objects,the inventive structure, method and computer program and computerprogram product are still applicable. Examples of computers and/orcomputing machines that do not utilize either classes and/or objectsinclude for example, the x86 computer architecture manufactured by IntelCorporation and others, the SPARC computer architecture manufactured bySun Microsystems, Inc and others, the Power PC computer architecturemanufactured by International Business Machines Corporation and others,and the personal computer products made by Apple Computer, Inc., andothers. For these types of computers, computing machines, informationappliances, and the virtual machine or virtual computing environmentsimplemented thereon that do not utilize the idea of classes or objects,may be generalized for example to include primitive data types (such asinteger data types, floating point data types, long data types, doubledata types, string data types, character data types and Boolean datatypes), structured data types (such a arrays and records) derived types,or other code or data structures of procedural languages or otherlanguages and environments such as functions, pointers, components,modules, structures, reference and unions. These structures andprocedures when applied in combination when required, maintain acomputing environment where memory locations, address ranges, objects,classes, assets, resources, or any other procedural or structural aspectof a computer or computing environment are where required created,maintained, operated, and deactivated or deleted in a coordinated,coherent, and consistent manner across the plurality of individualmachines M1, M2 . . . Mn.

This analysis or scrutiny of the application code 50 can take placeeither prior to loading the application program code 50, or during theapplication program code 50 loading procedure, or even after theapplication program code 50 loading procedure. It may be likened to aninstrumentation, program transformation, translation, or compilationprocedure in that the application code can be instrumented withadditional instructions, and/or otherwise modified by meaning-preservingprogram manipulations, and/or optionally translated from an input codelanguage to a different code language (such as for example fromsource-code language or intermediate-code language to object-codelanguage or machine-code language). In this connection it is understoodthat the term compilation normally or conventionally involves a changein code or language, for example, from source code to object code orfrom one language to another language. However, in the present instancethe term “compilation” (and its grammatical equivalents) is not sorestricted and can also include or embrace modifications within the samecode or language. For example, the compilation and its equivalents areunderstood to encompass both ordinary compilation (such as for exampleby way of illustration but not limitation, from source-code to objectcode), and compilation from source-code to source-code, as well ascompilation from object-code to object code, and any alteredcombinations therein. It is also inclusive of so-called“intermediary-code languages” which are a form of “pseudo object-code”.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 takes place during theloading of the application program code such as by the operating systemreading the application code 50 from the hard disk or other storagedevice or source and copying it into memory and preparing to beginexecution of the application program code. In another embodiment, in aJAVA virtual machine, the analysis or scrutiny may take place during theclass loading procedure of the java.lang.ClassLoader.loadClass method(e.g. “java.lang.ClassLoader.loadClass( )”).

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading procedure,such as after the operating system has loaded the application code intomemory, or optionally even after execution of the relevant correspondingportion of the application program code has started, such as for exampleafter the JAVA virtual machine has loaded the application code into thevirtual machine via the “java.lang.ClassLoader.loadClass( )” method andoptionally commenced execution.

Persons skilled in the computing arts will be aware of various possibletechniques that may be used in the modification of computer code,including but not limited to instrumentation, program transformation,translation, or compilation means.

One such technique is to make the modification(s) to the applicationcode, without a preceding or consequential change of the language of theapplication code. Another such technique is to convert the original code(for example, JAVA language source-code) into an intermediaterepresentation (or intermediate-code language, or pseudo code), such asJAVA byte code. Once this conversion takes place the modification ismade to the byte code and then the conversion may be reversed. Thisgives the desired result of modified JAVA code.

A further possible technique is to convert the application program tomachine code, either directly from source-code or via the abovementionedintermediate language or through some other intermediate means. Then themachine code is modified before being loaded and executed. A stillfurther such technique is to convert the original code to anintermediate representation, which is thus modified and subsequentlyconverted into machine code.

The present invention encompasses all such modification routes and alsoa combination of two, three or even more, of such routes.

The DRT or other code modifying means is responsible for creating orreplication a memory structure and contents on each of the individualmachines M1, M2 . . . Mn that permits the plurality of machines tointeroperate. In some embodiments this replicated memory structure willbe identical. Whilst in other embodiments this memory structure willhave portions that are identical and other portions that are not. Instill other embodiments the memory structures are different only informat or storage conventions such as Big Endian or Little Endianformats or conventions.

These structures and procedures when applied in combination whenrequired, maintain a computing environment where the memory locations,address ranges, objects, classes, assets, resources, or any otherprocedural or structural aspect of a computer or computing environmentare where required created, maintained, operated, and deactivated ordeleted in a coordinated, coherent, and consistent manner across theplurality of individual machines M1, M2 . . . Mn.

Therefore the terminology “one”, “single”, and “common” application codeor program includes the situation where all machines M1, M2 . . . Mn areoperating or executing the same program or code and not different (andunrelated) programs, in other words copies or replicas of same orsubstantially the same application code are loaded onto each of theinteroperating and connected machines or computers.

In conventional arrangements utilising distributed software, memoryaccess from one machine's software to memory physically located onanother machine takes place via the network interconnecting themachines. However, because the read and/or write memory access to memoryphysically located on another computer require the use of the slownetwork interconnecting the computers, in these configurations suchmemory accesses can result in substantial delays in memory read/writeprocessing operations, potentially of the order of 10⁶-10⁷ cycles of thecentral processing unit of the machine. Ultimately this delay isdependent upon numerous factors, such as for example, the speed,bandwidth, and/or latency of the communication network. This in largepart accounts for the diminished performance of the multipleinterconnected machines in the prior art arrangement.

However, in the present arrangement all reading of memory locations ordata is satisfied locally because a current value of all (or some subsetof all) memory locations is stored on the machine carrying out theprocessing which generates the demand to read memory.

Similarly, all writing of memory locations or data is satisfied locallybecause a current value of all (or some subset of all) memory locationsis stored on the machine carrying out the processing which generates thedemand to write to memory.

Such local memory read and write processing operation can typically besatisfied with 10²-10³ cycles of the central processing unit. Thus, inpractice there is substantially less waiting for memory accesses whichinvolves and/or writes.

The invention is transport, network, and communications pathindependent, and does not depend on how the communication betweenmachines or DRTs takes place. In one embodiment, even electronic mail(email) exchanges between machines or DRTs may suffice for thecommunications.

Turning now to FIG. 9, during the loading procedure 75, the program 50being loaded to create each JAVA virtual machine M1, M2, . . . Mn ismodified. This modification commences at 90 in FIG. 9 and involves theinitial step 91 of detecting all memory locations (termed fields inJAVA—but equivalent terms are used in other languages) in theapplication 50 being loaded. Such memory locations need to be identifiedfor subsequent processing at steps 92 and 93. The DRT 71/1, . . . DRT71/n during the loading procedure 75 creates a list of all the memorylocations thus identified, the JAVA fields being listed by object andclass. Both volatile and synchronous fields are listed.

The next phase (designated 92 in FIG. 9) of the modification procedureis to search through the executable application code in order to locateevery processing activity that manipulates or changes field valuescorresponding to the list generated at step 91 and thus writes to fieldsso the value at the corresponding memory location is changed. When suchan operation (typically putstatic or putfield in the JAVA language) isdetected which changes the field value, then an “updating propagationroutine” is inserted by step 93 at this place in the program to ensurethat all other machines are notified that the value of the field haschanged. Thereafter, the loading procedure continues in a normal way asindicated by step 94 in FIG. 9.

An alternative form of initial modification during loading isillustrated in FIG. 10. Here the start and listing steps 90 and 91 andthe searching step 92 are the same as in FIG. 9. However, rather thaninsert the “updating propagation routine” as in step 93 in which theprocessing thread carries out the updating, instead an “alert routine”is inserted at step 103. The “alert routine” instructs a thread orthreads not used in processing and allocated to the DRT, to carry outthe necessary propagation. This step 103 is a quicker alternative whichresults in lower overhead.

Once this initial modification during the loading procedure has takenplace, then either one of the multiple thread processing operationsillustrated in FIGS. 11 and 12 takes place. As seen in FIG. 11, multiplethread processing 110 on the machines consisting of threads 111/1 . . .111/4 is occurring and the processing of the second thread 111/2 (inthis example) results in that thread 111/2 becoming aware at step 113 ofa change of field value. At this stage the normal processing of thatthread 111/2 is halted at step 114, and the same thread 111/2 notifiesall other machines M2 . . . Mn via the network 53 of the identity of thechanged field and the changed value which occurred at step 113. At theend of that communication procedure, the thread 111/2 then resumes theprocessing at step 115 until the next instance where there is a changeof field value.

In the alternative arrangement illustrated in FIG. 12, once a thread121/2 has become aware of a change of field value at step 113, itinstructs DRT processing 120 (as indicated by step 125 and arrow 127)that another thread(s) 121/1 allocated to the DRT processing 120 is topropagate in accordance with step 128 via the network 53 to all othermachines M2 . . . Mn the identity of the changed field and the changedvalue detected at step 113. This is an operation which can be carriedout quickly and thus the processing of the initial thread 111/2 is onlyinterrupted momentarily as indicated in step 125 before the thread 111/2resumes processing in step 115. The other thread 121/1 which has beennotified of the change (as indicated by arrow 127) then communicatesthat change as indicated in step 128 via the network 53 to each of theother machines M2 . . . Mn.

This second arrangement of FIG. 12 makes better utilisation of theprocessing power of the various threads 111/1 . . . 111/3 and 121/1(which are not, in general, subject to equal demands) and gives betterscaling with increasing size of “n”, (n being an integer greater than orequal to 2 which represents the total number of machines which areconnected to the network 53 and which run the application program 50simultaneously). Irrespective of which arrangement is used, the changedfield and identities and values detected at step 113 are propagated toall the other machines M2 . . . Mn on the network.

This is illustrated in FIG. 13 where the DRT 71/1 and its thread 121/1of FIG. 12 (represented by step 128 in FIG. 13) sends via the network 53the identity and changed value of the listed memory location generatedat step 113 of FIG. 12 by processing in machine M1, to each of the othermachines M2 . . . Mn.

Each of the other machines M2 . . . Mn carries out the action indicatedby steps 135 and 136 in FIG. 13 for machine Mn by receiving the identityand value pair from the network 53 and writing the new value into thelocal corresponding memory location.

In the prior art arrangement in FIG. 3 utilising distributed software,memory accesses from one machine's software to memory physically locatedon another machine are permitted by the network interconnecting themachines. However, such memory accesses can result in delays inprocessing of the order of 10⁶-10⁷ cycles of the central processing unitof the machine. This in large part accounts for the diminishedperformance of the multiple interconnected machines.

However, in the present arrangement as described above in connectionwith FIG. 8, it will be appreciated that all reading of data issatisfied locally because the current value of all fields is stored onthe machine carrying out the processing which generates the demand toread memory. Such local processing can be satisfied within 10²-10³cycles of the central processing unit. Thus, in practice, there issubstantially no waiting for memory accesses which involves reads.

However, most application software reads memory frequently but writes tomemory relatively infrequently. As a consequence, the rate at whichmemory is being written or re-written is relatively slow compared to therate at which memory is being read. Because of this slow demand forwriting or re-writing of memory, the fields can be continually updatedat a relatively low speed via the inexpensive commodity network 53, yetthis low speed is sufficient to meet the application program's demandfor writing to memory. The result is that the performance of the FIG. 8arrangement is vastly superior to that of FIG. 3.

In a further modification in relation to the above, the identities andvalues of changed fields can be grouped into batches so as to furtherreduce the demands on the communication speed of the network 53interconnecting the various machines.

It will also be apparent to those skilled in the art that in a tablecreated by each DRT 71 when initially recording the fields, for eachfield there is a name or identity which is common throughout the networkand which the network recognises. However, in the individual machinesthe memory location corresponding to a given named field will vary overtime since each machine will progressively store changed field values atdifferent locations according to its own internal processes. Thus thetable in each of the DRTs will have, in general, different memorylocations but each global “field name” will have the same “field value”stored in the different memory locations.

It will also be apparent to those skilled in the art that theabove-mentioned modification of the application program during loadingcan be accomplished in up to five ways by:

(i) re-compilation at loading,(ii) by a pre-compilation procedure prior to loading,(iii) compilation prior to loading,(iv) a “just-in-time” compilation, or(v) re-compilation after loading (but, or for example, before executionof the relevant or corresponding application code in a distributedenvironment).

Traditionally the term “compilation” implies a change in code orlanguage, eg from source to object code or one language to another.Clearly the use of the term “compilation” (and its grammaticalequivalents) in the present specification is not so restricted and canalso include or embrace modifications within the same code or language.

In the first embodiment, a particular machine, say machine M2, loads theapplication code on itself, modifies it, and then loads each of theother machines M1, M3 . . . Mn (either sequentially or simultaneously)with the modified code. In this arrangement, which may be termed“master/slave”, each of machines M1, M3, . . . Mn loads what it is givenby machine M2.

In a still further embodiment, each machine receives the applicationcode, but modifies it and loads the modified code on that machine. Thisenables the modification carried out by each machine to be slightlydifferent being optimized based upon its architecture and operatingsystem, yet still coherent with all other similar modifications.

In a further arrangement, a particular machine, say M1, loads theunmodified code and all other machines M2, M3 . . . Mn do a modificationto delete the original application code and load the modified version.

In all instances, the supply can be branched (ie M2 supplies each of M1,M3, M4, etc directly) or cascaded or sequential (ie M2 applies M1 whichthen supplies M3 which then supplies M4, and so on).

In a still further arrangement, the machines M1 to Mn, can send all loadrequests to an additional machine (not illustrated) which is not runningthe application program, which performs the modification via any of theaforementioned methods, and returns the modified routine to each of themachines M1 to Mn which then load the modified routine locally. In thisarrangement, machines M1 to Mn forward all load requests to thisadditional machine which returns a modified routine to each machine. Themodifications performed by this additional machine can include any ofthe modifications covered under the scope of the present invention.

Persons skilled in the computing arts will be aware of at least fourtechniques used in creating modifications in computer code. The first isto make the modification in the original (source) language. The secondis to convert the original code (in say JAVA) into an intermediaterepresentation (or intermediate language). Once this conversion takesplace the modification is made and then the conversion is reversed. Thisgives the desired result of modified JAVA code.

The third possibility is to convert to machine code (either directly orvia the abovementioned intermediate language). Then the machine code ismodified before being loaded and executed. The fourth possibility is toconvert the original code to an intermediate representation, which isthen modified and subsequently converted into machine code.

The present invention encompasses all four modification routes and alsoa combination of two, three or even all four, of such routes.

Memory Management and Replication

In connection with FIG. 5, in accordance with a preferred embodiment ofthe present invention a single application code 50 (sometimes moreinformally referred to as the application or the application program)can be operated simultaneously on a number of machines M1, M2 . . . Mninterconnected via a communications network or other communications linkor path 53. By way of example but not limitation, one application codeor program 50 would be a single common application program on themachines, such as Microsoft Word, as opposed to different applicationson each machine, such as Microsoft Word on machine M1, and MicrosoftPowerPoint on machine M2, and Netscape Navigator on machine M3 and soforth. Therefore the terminology “one”, “single”, and “common”application code or program is used to try and capture this situationwhere all machines M1, . . . , Mn are operating or executing the sameprogram or code and not different (and unrelated) programs. In otherwords copies or replicas of same or substantially the same applicationcode is loaded onto each of the interoperating and connected machines orcomputers. As the characteristics of each machine or computer maydiffer, the application code 50 may be modified before loading, duringthe loading process, or after the loading process to provide acustomization or modification of the code on each machine. Somedissimilarity between the programs may be permitted so long as the otherrequirements for interoperability, consistency, and coherency asdescribed herein can be maintain. As it will become apparent hereafter,each of the machines M1, M2 . . . Mn operates with the same applicationcode 50 on each machine M1, M2 . . . Mn and thus all of the machines M1,M2, . . . , Mn have the same or substantially the same application code50 usually with a modification that may be machine specific.

Similarly, each of the machines M1, M2, . . . , Mn operates with thesame (or substantially the same or similar) modifier 51 on each machineM1, M2, . . . , Mn and thus all of the machines M1, M2 . . . Mn have thesame (or substantially the same or similar) modifier 51 with themodifier of machine M1 being designated 51/1 and the modifier of machineM2 being designated 51/2, etc. In addition, before or during the loadingof, or preceding the execution of, or even after execution hascommenced, the application code 50 on each machine M1, M2 . . . Mn ismodified by the corresponding modifier 51 according to the same rules(or substantially the same rules since minor optimizing changes arepermitted within each modifier 51/1, 51/2, . . . , 51/n).

As will become more apparent in light of the further descriptionprovided herein, one of the features of the invention is to make itappear that one application program instance of application code 50 isexecuting simultaneously across all of the plurality of machines M1, M2,. . . , Mn. As will be described in considerable detail hereinafter, theinstant invention achieves this by running the same application programcode (for example, Microsoft Word or Adobe Photoshop CS2) on eachmachine, but modifying the executable code of that application programon each machine such that each executing occurrence (or ‘localinstance’) on each one of the machines M1 . . . Mn coordinates its localoperations with the operations of the respective occurrences on each oneof the other machines such that each occurrence on each one of theplurality of machines function together in a consistent, coherent andcoordinated manner so as to give the appearance of being one globalinstance (or occurrence) of the application program and program code(i.e., a “meta-application”).

As a consequence of the above described arrangement, if each of themachines M1, M2, . . . , Mn has, say, an internal memory capability of10 MB, then the total memory available to each application code 50 isnot necessarily, as one might expect the number of machines (n) times 10MB, or alternatively the additive combination of the internal memorycapability of all n machines, but rather or still may only be 10 MB. Inthe situation where the internal memory capacities of the machines aredifferent, which is permissible, then in the case where the internalmemory in one machine is smaller than the internal memory capability ofat least one other of the machines, then the size of the smallest memoryof any of the machines may be used as the maximum memory capacity of themachines when such memory (or a portion thereof) is to be treated as a‘common’ memory (i.e. similar equivalent memory on each of the machinesM1 . . . Mn) or otherwise used to execute the common application code.

However, even though the manner that the internal memory of each machineis treated may initially appear to be a possible constraint onperformance, how this results in improved operation and performance willbecome apparent hereafter. Naturally, each machine M1, M2 . . . Mn has aprivate (i.e. ‘non-common’) internal memory capability. The privateinternal memory capability of the machines M1, M2, . . . , Mn arenormally approximately equal but need not be. It may also beadvantageous to select the amounts of internal memory in each machine toachieve a desired performance level in each machine and across aconstellation or network of connected or coupled plurality of machines,computers, or information appliances M1, M2, . . . , Mn. Havingdescribed these internal and common memory considerations, it will beapparent in light of the description provided herein that the amount ofmemory that can be common between machines is not a limitation of theinvention.

It is known from the prior art to operate a single computer or machine(produced by one of various manufacturers and having an operating systemoperating in one of various different languages) in a particularlanguage of the application, by creating a virtual machine asschematically illustrated in FIG. 6. The code and data and virtualmachine configuration or arrangement of FIG. 6 takes the form of theapplication code 50 written in the Java language and executing within aJava Virtual Machine 61. Thus, where the intended language of theapplication is the language JAVA, a JAVA virtual machine is used whichis able to operate code in JAVA irrespective of the machine manufacturerand internal details of the machine. For further details see “The JAVAVirtual Machine Specification” 2^(nd) Edition by T. Lindholm & F. Yellinof Sun Microsystems Inc. of the USA, which is incorporated by referenceherein.

This conventional art arrangement of FIG. 6 is modified in accordancewith embodiments of the present invention by the provision of anadditional facility which is conveniently termed “distributed run time”or “distributed run time system” DRT 71 and as seen in FIG. 7.

In FIG. 7, the application code 50 is loaded onto the Java VirtualMachine 72 in cooperation with the distributed runtime system 71,through the loading procedure indicated by arrow 75. As used herein theterms distributed runtime and the distributed run time system areessentially synonymous, and by means of illustration but not limitationare generally understood to include library code and processes whichsupport software written in a particular language running on aparticular platform. Additionally, a distributed runtime system may alsoinclude library code and processes which support software written in aparticular language running within a particular distributed computingenvironment. The runtime system typically deals with the details of theinterface between the program and the operation system such as systemcalls, program start-up and termination, and memory management. Forpurposes of background, a conventional Distributed Computing Environment(DCE) that does not provide the capabilities of the inventivedistributed run time or distributed run time system 71 required in theinvention is available from the Open Software Foundation. ThisDistributed Computing Environment (DCE) performs a form ofcomputer-to-computer communication for software running on the machines,but among its many limitations, it is not able to implement themodification or communication operations of this invention. Among itsfunctions and operations, the inventive DRT 71 coordinates theparticular communications between the plurality of machines M1, M2, . .. , Mn. Moreover, the inventive distributed runtime 71 comes intooperation during the loading procedure indicated by arrow 75 of the JAVAapplication 50 on each JAVA virtual machine 72 of machines JVM#1, JVM#2,. . . JVM#n. The sequence of operations during loading will be describedhereafter in relation to FIG. 9. It will be appreciated in light of thedescription provided herein that although many examples and descriptionsare provided relative to the JAVA language and JAVA virtual machines sothat the reader may get the benefit of specific examples, the inventionis not restricted to either the JAVA language or JAVA virtual machines,or to any other language, virtual machine, machine, or operatingenvironment.

FIG. 8 shows in modified form the arrangement of FIG. 5 utilising JAVAvirtual machines, each as illustrated in FIG. 7. It will be apparentthat again the same application code 50 is loaded onto each machine M1,M2 . . . Mn. However, the communications between each machine M1, M2, .. . , Mn, and indicated by arrows 83, although physically routed throughthe machine hardware, are advantageously controlled by the individualDRT's 71/1 . . . 71/n within each machine. Thus, in practice this may beconceptionalised as the DRT's 71/1, . . . , 71/n communicating with eachother via the network or other communications link 73 rather than themachines M1, M2, . . . , Mn communicating directly with themselves oreach other. Actually, the invention contemplates and included eitherthis direct communication between machines M1, M2, . . . , Mn or DRTs71/1, 71/2, . . . , 71/n or a combination of such communications. Theinventive DRT 71 provides communication that is transport, protocol, andlink independent.

It will be appreciated in light of the description provided herein thatthere are alternative implementations of the modifier 51 and thedistributed run time 71. For example, the modifier 51 may be implementedas a component of or within the distributed run time 71, and thereforethe DRT 71 may implement the functions and operations of the modifier51. Alternatively, the function and operation of the modifier 51 may beimplemented outside of the structure, software, firmware, or other meansused to implement the DRT 71. In one embodiment, the modifier 51 and DRT71 are implemented or written in a single piece of computer program codethat provides the functions of the DRT and modifier. The modifierfunction and structure therefore maybe subsumed into the DRT andconsidered to be an optional component. Independent of how implemented,the modifier function and structure is responsible for modifying theexecutable code of the application code program, and the distributed runtime function and structure is responsible for implementingcommunications between and among the computers or machines. Thecommunications functionality in one embodiment is implemented via anintermediary protocol layer within the computer program code of the DRTon each machine. The DRT may for example implement a communicationsstack in the JAVA language and use the Transmission ControlProtocol/Internet Protocol (TCP/IP) to provide for communications ortalking between the machines. Exactly how these functions or operationsare implemented or divided between structural and/or proceduralelements, or between computer program code or data structures within theinvention are less important than that they are provided.

However, in the arrangement illustrated in FIG. 8, (and also in FIGS.31-32), a plurality of individual computers or machines M1, M2, . . . ,Mn are provided, each of which are interconnected via a communicationsnetwork 53 or other communications link and each of which individualcomputers or machines provided with a modifier 51 (See in FIG. 5) andrealised by or in for example the distributed run time (DRT) 71 (SeeFIG. 8) and loaded with a common application code 50. The term commonapplication program is to be understood to mean an application programor application program code written to operate on a single machine, andloaded and/or executed in whole or in part on each one of the pluralityof computers or machines M1, M2 . . . Mn, or optionally on each one ofsome subset of the plurality of computers or machines M1, M2 . . . Mn.Put somewhat differently, there is a common application programrepresented in application code 50, and this single copy or perhaps aplurality of identical copies are modified to generate a modified copyor version of the application program or program code, each copy orinstance prepared for execution on the plurality of machines. At thepoint after they are modified they are common in the sense that theyperform similar operations and operate consistently and coherently witheach other. It will be appreciated that a plurality of computers,machines, information appliances, or the like implementing the featuresof the invention may optionally be connected to or coupled with othercomputers, machines, information appliances, or the like that do notimplement the features of the invention.

Essentially in at least one embodiment the modifier 51 or DRT 71 orother code modifying means is responsible for modifying the applicationcode 50 so that it may execute memory manipulation operations, such asmemory putstatic and putfield instructions in the JAVA language andvirtual machine environment, in a coordinated, consistent, and coherentmanner across and between the plurality of individual machines M1 . . .Mn. It follows therefore that in such a computing environment it isnecessary to ensure that each of memory location is manipulated in aconsistent fashion (with respect to the others).

In some embodiments, some- or all of the plurality of individualcomputers or machines may be contained within a single housing orchassis (such as so-called “blade servers” manufactured byHewlett-Packard Development Company, Intel Corporation, IBM Corporationand others) or implemented on a single printed circuit board or evenwithin a single chip or chip set.

A machine (produced by any one of various manufacturers and having anoperating system operating in any one of various different languages)can operate in the particular language of the application program code50, in this instance the JAVA language. That is, a JAVA virtual machine72 is able to operate application code 50 in the JAVA language, andutilize the JAVA architecture irrespective of the machine manufacturerand the internal details of the machine.

When implemented in a non-JAVA language or application code environment,the generalized platform, and/or virtual machine and/or machine and/orruntime system is able to operate application code 50 in the language(s)(possibly including for example, but not limited to any one or more ofsource-code languages, intermediate-code languages, object-codelanguages, machine-code languages, and any other code languages) of thatplatform, and/or virtual machine and/or machine and/or runtime systemenvironment, and utilize the platform, and/or virtual machine and/ormachine and/or runtime system and/or language architecture irrespectiveof the machine manufacturer and the internal details of the machine. Itwill also be appreciated in light of the description provided hereinthat platform and/or runtime system may include virtual machine andnon-virtual machine software and/or firmware architectures, as well ashardware and direct hardware coded applications and implementations.

For a more general set of virtual machine or abstract machineenvironments, and for current and future computers and/or computingmachines and/or information appliances or processing systems, and thatmay not utilize or require utilization of either classes and/or objects,the inventive structure, method, and computer program and computerprogram product are still applicable. Examples of computers and/orcomputing machines that do not utilize either classes and/or objectsinclude for example, the x86 computer architecture manufactured by IntelCorporation and others, the SPARC computer architecture manufactured bySun Microsystems, Inc and others, the PowerPC computer architecturemanufactured by International Business Machines Corporation and others,and the personal computer products made by Apple Computer, Inc., andothers. For these types of computers, computing machines, informationappliances, and the virtual machine or virtual computing environmentsimplemented thereon that do not utilize the idea of classes or objects,may be generalized for example to include primitive data types (such asinteger data types, floating point data types, long data types, doubledata types, string data types, character data types and Boolean datatypes), structured data types (such as arrays and records) derivedtypes, or other code or data structures of procedural languages or otherlanguages and environments such as functions, pointers, components,modules, structures, references and unions.

Turning now to FIGS. 7 and 9, during the loading procedure 75, theapplication code 50 being loaded onto or into each JAVA virtual machine72 is modified by DRT 71. This modification commences at Step 90 in FIG.9 and involves the initial step 91 of preferably scrutinizing oranalysing the code and detecting all memory locations addressable by theapplication code 50, or optionally some subset of all memory locationsaddressable by the application code 50; such as for example named andunnamed memory locations, variables (such as local variables, globalvariables, and formal arguments to subroutines or functions), fields,registers, or any other address space or range of addresses whichapplication code 50 may access. Such memory locations in some instancesneed to be identified for subsequent processing at steps 92 and 93. Insome embodiments, where a list of detected memory locations is requiredfor further processing, the DRT 71 during the loading procedure 75creates a list of all the memory locations thus identified. In oneembodiment, the memory locations in the form of JAVA fields are listedby object and class, however, the memory locations, fields, or the likemay be listed or organized in any manner so long as they comport withthe architectural and programming requirements of the system on whichthe program is to be used and the principles of the invention describedherein. This detection is optional and not required in all embodimentsof the invention. It may be noted that the DRT is at least in partfulfilling the roll of the modifier 51.

The next phase (designated Step 92 in FIG. 9) [Step 92] of themodification procedure is to search through the application code 50 inorder to locate processing activity or activities that manipulate orchange values or contents of any listed memory location (for example,but not limited to JAVA fields) corresponding to the list generated atstep 91 when required. Preferably, all processing activities thatmanipulate or change any one or more values or contents of any one ormore listed memory locations, are located.

When such a processing activity or operation (typically “putstatic” or“putfield” in the JAVA language, or for example, a memory assignmentoperation, or a memory write operation, or a memory manipulationoperation, or more generally operations that otherwise manipulate orchange value(s) or content(s) of memory or other addressable areas), isdetected which changes the value or content of a listed or detectedmemory location, then an “updating propagation routine” is inserted bystep 93 in the application code 50 corresponding to the detected memorymanipulation operation, to communicate with all other machines in orderto notify all other machines of the identity of the manipulated memorylocation, and the updated, manipulated or changed value(s) or content(s)of the manipulated memory location. The inserted “updating propagationroutine” preferably takes the form of a method, function, procedure, orsimilar subroutine call or operation to a network communications libraryof DRT 71. Alternatively, the “updating propagation routine” may takethe optional form of a code-block (or other inline code form) insertedinto the application code instruction stream at, after, before, orotherwise corresponding to the detected manipulation instruction oroperation. And preferably, in a multi-tasking or parallel processingmachine environment (and in some embodiments inclusive or exclusive ofoperating system), such as a machine environment capable of potentiallysimultaneous or concurrent execution of multiple or different threads orprocesses, the “updating propagation routine” may execute on the samethread or process or processor as the detected memory manipulationoperation of step 92. Thereafter, the loading procedure continues, byloading the modified application code 50 on the machine 72 in place ofthe unmodified application code 50, as indicated by step 94 in FIG. 9.

An alternative form of modification during loading is illustrated in theillustration of FIG. 10. Here the start and listing steps 90 and 91 andthe searching step 92 are the same as in FIG. 9. However, rather thaninsert the “updating propagation routine” into the application code 50corresponding to the detected memory manipulation operation identifiedin step 92, as is indicated in step 93, in which the application code50, or network communications library code 71 of the DRT executing onthe same thread or process or processor as the detected memorymanipulation operation, carries out the updating, instead an “alertroutine” is inserted corresponding to the detected memory manipulationoperation, at step 103. The “alert routine” instructs, notifies orotherwise requests a different and potentially simultaneously orconcurrently executing thread or process or processor not used toperform the memory manipulation operation (that is, a different threador process or processor than the thread or process or processor whichmanipulated the memory location), such as a different thread or processallocated to the DRT 71, to carry out the notification, propagation, orcommunication of all other machines of the identity of the manipulatedmemory location, and the updated, manipulated or changed value(s) orcontent(s) of the manipulated memory location.

Once this modification during the loading procedure has taken place andexecution begins of the modified application code 50, then either thesteps of FIG. 11 or FIG. 12 take place. FIG. 11 (and the steps 112, 113,114, and 115 therein) correspond to the execution and operation of themodified application code 50 when modified in accordance with theprocedures set forth in and described relative to FIG. 9. FIG. 12 on theother hand (and the steps 112, 113, 125, 127, and 115 therein) set forththerein correspond to the execution and operation of the modifiedapplication code 50 when modified in accordance with FIG. 10.

This analysis or scrutiny of the application code 50 can take placeeither prior to loading the application program code 50, or during theapplication program code 50 loading procedure, or even after theapplication program code 50 loading procedure. It may be likened to aninstrumentation, program transformation, translation, or compilationprocedure in that the application code may be instrumented withadditional instructions, and/or otherwise modified by meaning-preservingprogram manipulations, and/or optionally translated from an input codelanguage to a different code language (such as for example fromsource-code language or intermediate-code language to object-codelanguage or machine-code language), and with the understanding that theterm compilation normally or conventionally involves a change in code orlanguage, for example, from source code to object code or from onelanguage to another language. However, in the present instance the term“compilation” (and its grammatical equivalents) is not so restricted andcan also include or embrace modifications within the same code orlanguage. For example, the compilation and its equivalents areunderstood to encompass both ordinary compilation (such as for exampleby way of illustration but not limitation, from source-code toobject-code), and compilation from source-code to source-code, as wellas compilation from object-code to object-code, and any alteredcombinations therein. It is also inclusive of so-called“intermediary-code languages” which are a form of “pseudo object-code”.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 may take place duringthe loading of the application program code such as by the operatingsystem reading the application code from the hard disk or other storagedevice or source and copying it into memory and preparing to beginexecution of the application program code. In another embodiment, in aJAVA virtual machine, the analysis or scrutiny may take place during theclass loading procedure of the java.lang.ClassLoader loadClass method(e.g., “java.lang.ClassLoader.loadClass( )”).

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading procedure,such as after the operating system has loaded the application code intomemory, or optionally even after execution of the relevant correspondingportion of the application program code has started, such as for exampleafter the JAVA virtual machine has loaded the application code into thevirtual machine via the “java.lang.ClassLoader.loadClass( )” method andoptionally commenced execution.

As seen in FIG. 11, a multiple thread processing machine environment110, on each one of the machines M1, . . . , Mn and consisting ofthreads 111/1 . . . 111/4 exists. The processing and execution of thesecond thread 111/2 (in this example) results in that thread 111/2manipulating a memory location at step 113, by writing to a listedmemory location. In accordance with the modifications made to theapplication code 50 in the steps 90-94 of FIG. 9, the application code50 is modified at a point corresponding to the write to the memorylocation of step 113, so that it propagates, notifies, or communicatesthe identity and changed value of the manipulated memory location ofstep 113 to the other machines M2, . . . , Mn via network 53 or othercommunication link or path, as indicated at step 114. At this stage theprocessing of the application code 50 of that thread 111/2 is or may bealtered and in some instances interrupted at step 114 by the executingof the inserted “updating propagation routine”, and the same thread111/2 notifies, or propagates, or communicates to all other machines M2,. . . , Mn via the network 53 or other communications link or path ofthe identity and changed value of the manipulated memory location ofstep 113. At the end of that notification, or propagation, orcommunication procedure 114, the thread 111/2 then resumes or continuesthe processing or the execution of the modified application code 50 atstep 115.

In the alternative arrangement illustrated in FIG. 12, a multiple threadprocessing machine environment 110 comprising or consisting of threads111/1, . . . , 111/3, and a simultaneously or concurrently executing DRTprocessing environment 120 consisting of the thread 121/1 asillustrated, or optionally a plurality of threads, is executing on eachone of the machines M1, . . . Mn. The processing and execution of themodified application code 50 on thread 111/2 results in a memorymanipulation operation of step 113, which in this instance is a write toa listed memory location. In accordance with the modifications made tothe application code 50 in the steps 90, 91, 92, 103, and 94 of FIG. 9,the application code 50 is modified at a point corresponding to thewrite to the memory location of step 113, so that it requests orotherwise notifies the threads of the DRT processing environment 120 tonotify, or propagate, or communicate to the other machines M2, . . . ,Mn of the identity and changed value of the manipulated memory locationof step 113, as indicated at steps 125 and 128 and arrow 127. Inaccordance with this modification, the thread 111/2 processing andexecuting the modified application code 50 requests a different andpotentially simultaneously or concurrently executing thread or process(such as thread 121/1) of the DRT processing environment 120 to notifythe machines M2, . . . , Mn via network 53 or other communications linkor path of the identity and changed value of the manipulated memorylocation of step 113, as indicated in step 125 and arrow 127. Inresponse to this request of step 125 and arrow 127, a different andpotentially simultaneously or concurrently executing thread or process121/1 of the DRT processing environment 120 notifies the machines M2, .. . , Mn via network 53 or other communications link or path of theidentity and changed value of the manipulated memory location of step113, as requested of it by the modified application code 50 executing onthread 111/2 of step 125 and arrow 127.

When compared to the earlier described step 114 of thread 111/2 of FIG.11, step 125 of thread 111/2 of FIG. 12 can be carried out quickly,because step 114 of thread 111/2 must notify and communicate withmachines M2, . . . , Mn via the relatively slow network 53 (relativelyslow for example when compared to the internal memory bus 4 of FIG. 1 orthe global memory 13 of FIG. 2) of the identity and changed value of themanipulated memory location of step 113, whereas step 125 of thread111/2 does not communicate with machines M2, . . . , Mn via therelatively slow network 53. Instead, step 125 of thread 111/2 requestsor otherwise notifies a different and potentially simultaneously orconcurrently executing thread 121/1 of the DRT processing environment120 to perform the notification and communication with machines M2, . .. , Mn via the relatively slow network 53 of the identify and changedvalue of the manipulated memory location of step 113, as indicated byarrow 127. Thus thread 111/2 carrying out step 125 is only interruptedmomentarily before the thread 111/2 resumes or continues processing orexecution of modified application code in step 115. The other thread121/1 of the DRT processing environment 120 then communicates theidentity and changed value of the manipulated memory location of step113 to machines M2, Mn via the relatively slow network 53 or otherrelatively slow communications link or path.

This second arrangement of FIG. 12 makes better utilisation of theprocessing power of the various threads 111/1 . . . 111/3 and 121/1(which are not, in general, subject to equal demands). Irrespective ofwhich arrangement is used, the identity and change value of themanipulated memory location(s) of step 113 is (are) propagated to allthe other machines M2 . . . Mn on the network 53 or other communicationslink or path.

This is illustrated in FIG. 13 where step 114 of FIG. 11, or the DRT71/1 (corresponding to the DRT processing environment 120 of FIG. 12)and its thread 121/1 of FIG. 12 (represented by step 128 in FIG. 13),send, via the network 53 or other communications link or path, theidentity and changed value of the manipulated memory location of step113 of FIGS. 11 and 12, to each of the other machines M2, . . . , Mn.

With reference to FIG. 13, each of the other machines M2, . . . , Mncarries out the action of receiving from the network 53 the identity andchanged value of, for example, the manipulated memory location of step113 from machine M1, indicated by step 135, and writes the valuereceived at step 135 to the local memory location corresponding to theidentified memory location received at step 135, indicated by step 136.

In the conventional arrangement in FIG. 3 utilising distributedsoftware, memory access from one machine's software to memory physicallylocated on another machine is permitted by the network interconnectingthe machines. However, because the read and/or write memory access tomemory physically located on another computer require the use of theslow network 14, in these configurations such memory accesses can resultin substantial delays in memory read/write processing operation,potentially of the order of 10⁶-10⁷ cycles of the central processingunit of the machine, but ultimately being dependant upon numerousfactors, such as for example, the speed, bandwidth, and/or latency ofthe network 14. This in large part accounts for the diminishedperformance of the multiple interconnected machines in the prior artarrangement of FIG. 3.

However, in the present arrangement as described above in connectionwith FIG. 8, it will be appreciated that all reading of memory locationsor data is satisfied locally because a current value of all (or somesubset of all) memory locations is stored on the machine carrying outthe processing which generates the demand to read memory.

Similarly, in the present arrangement as described above in connectionwith FIG. 8, it will be appreciated that all writing of memory locationsor data may be satisfied locally because a current value of all (or somesubset of all) memory locations is stored on the machine carrying outthe processing which generates the demand to write to memory.

Such local memory read and write processing operation as performedaccording to the invention can typically be satisfied within 10²-10³cycles of the central processing unit. Thus, in practice, there issubstantially less waiting for memory accesses which involves reads thanthe arrangement shown and described relative to FIG. 3. Additionally, inpractice, there may be less waiting for memory accesses which involvewrites than the arrangement shown and described relative to FIG. 3.

It may be appreciated that most application software reads memoryfrequently but writes to memory relatively infrequently. As aconsequence, the rate at which memory is being written or re-written isrelatively slow compared to the rate at which memory is being read.Because of this slow demand for writing or re-writing of memory, thememory locations or fields can be continually updated at a relativelylow speed via the possibly relatively slow and inexpensive commoditynetwork 53, yet this possibly relatively slow speed is sufficient tomeet the application program's demand for writing to memory. The resultis that the performance of the FIG. 8 arrangement is superior to that ofFIG. 3. It may be appreciated in light of the description providedherein that while a relatively slow network communication link or path53 may advantageously be used because it provides the desiredperformance and low cost, the invention is not limited to a relativelylow speed network connection and may be used with any communication linkor path. The invention is transport, network, and communications pathindependent, and does not depend on how the communication betweenmachines or DRTs takes place. In one embodiment, even electronic mail(email) exchanges between machines or DRTs may suffice for thecommunications.

In a further optional modification in relation to the above, theidentity and changed value pair of a manipulated memory location sentover network 53, each pair typically sent as the sole contents of asingle packet, frame or cell for example, can be grouped into batches ofmultiple pairs of identities and changed values corresponding tomultiple manipulated memory locations, and sent together over network 53or other communications link or path in a single packet, frame, or cell.This further modification further reduces the demands on thecommunication speed of the network 53 or other communications link orpath interconnecting the various machines, as each packet, cell or framemay contain multiple identity and changed value pairs, and thereforefewer packets, frames, or cells require to be sent.

It may be apparent that in an environment where the application programcode writes repeatedly to a single memory location, the embodimentillustrated of FIG. 11 of step 114 sends an updating and propagationmessage to all machines corresponding to every performed memorymanipulation operation. In a still further optimal modification inrelation to the above, the DRT thread 121/1 of FIG. 12 does not need toperform an updating and propagation operation corresponding to everylocal memory manipulation operation, but instead may send fewer updatingand propagation messages than memory manipulation operations, eachmessage containing the last or latest changed value or content of themanipulated memory location, or optionally may only send a singleupdating and propagation message corresponding to the last memorymanipulation operation. This further improvement reduces the demands onthe network 53 or other communications link or path, as fewer packets,frames, or cells require to be sent.

It will also be apparent to those skilled in the art in light of thedetailed description provided herein that in a table or list or otherdata structure created by each DRT 71 when initially recording orcreating the list of all, or some subset of all, memory locations (orfields), for each such recorded memory location on each machine M1, . .. , Mn there is a name or identity which is common or similar on each ofthe machines M2, . . . , Mn. However, in the individual machines thelocal memory location corresponding to a given name or identity (listedfor example, during step 91 of FIG. 9) will or may vary over time sinceeach machine may and generally will store changed memory values orcontents at different memory locations according to its own internalprocesses. Thus the table, or list, or other data structure in each ofthe DRTs will have, in general, different local memory locationscorresponding to a single memory name or identity, but each global“memory name” or identity will have the same “memory value” stored inthe different local memory locations.

It will also be apparent to those skilled in the art in light of thedescription provided herein that the abovementioned modification of theapplication program code 50 during loading can be accomplished in manyways or by a variety of means. These ways or means include, but are notlimited to at least the following five ways and variations orcombinations of these five, including by:

(i) re-compilation at loading,(ii) by a pre-compilation procedure prior to loading,(iii) compilation prior to loading,(iv) a “just-in-time” compilation, or(v) re-compilation after loading (but, or for example, before executionof the relevant or corresponding application code in a distributedenvironment).

Traditionally the term “compilation” implies a change in code orlanguage, for example, from source to object code or one language toanother. Clearly the use of the term “compilation” (and its grammaticalequivalents) in the present specification is not so restricted and canalso include or embrace modifications within the same code or language.

Given the fundamental concept of modifying memory manipulationoperations to coordinate operation between and amongst a plurality ofmachines M1 . . . Mn, there are several different ways or embodiments inwhich this coordinated, coherent and consistent memory state andmanipulation operation concept, method, and procedure may be carried outor implemented.

In the first embodiment, a particular machine, say machine M2, loads theasset (such as class or object) inclusive of memory manipulationoperation(s), modifies it, and then loads each of the other machines M1,M3, . . . , Mn (either sequentially or simultaneously or according toany other order, routine or procedure) with the modified object (orclass or other asset or resource) inclusive of the new modified memorymanipulation operation. Note that there may be one or a plurality ofmemory manipulation operations corresponding to only one object in theapplication code, or there may be a plurality of memory manipulationoperations corresponding to a plurality of objects in the applicationcode. Note that in one embodiment, the memory manipulation operation(s)that is (are) loaded is binary executable object code. Alternatively,the memory manipulation operation(s) that is (are) loaded is executableintermediary code.

In this arrangement, which may be termed “master/slave” each of theslave (or secondary) machines M1, M3, . . . , Mn loads the modifiedobject (or class), and inclusive of the new modified memory manipulationoperation(s), that was sent to it over the computer communicationsnetwork or other communications link or path by the master (or primary)machine, such as machine M2, or some other machine such as a machine Xof FIG. 15. In a slight variation of this “master/slave” or“primary/secondary” arrangement, the computer communications network canbe replaced by a shared storage device such as a shared file system, ora shared document/file repository such as a shared database.

Note that the modification performed on each machine or computer neednot and frequently will not be the same or identical. What is requiredis that they are modified in a similar enough way that in accordancewith the inventive principles described herein, each of the plurality ofmachines behaves consistently and coherently relative to the othermachines to accomplish the operations and objectives described herein.Furthermore, it will be appreciated in light of the description providedherein that there are a myriad of ways to implement the modificationsthat may for example depend on the particular hardware, architecture,operating system, application program code, or the like or differentfactors. It will also be appreciated that embodiments of the inventionmay be implemented within an operating system, outside of or without thebenefit of any operating system, inside the virtual machine, in anEPROM, in software, in firmware, or in any combination of these.

In a still further embodiment, each machine M1, . . . , Mn receives theunmodified asset (such as class or object) inclusive of one or morememory manipulation operation(s), but modifies the operations and thenloads the asset (such as class or object) consisting of the now modifiedoperations. Although one machine, such as the master or primary machinemay customize or perform a different modification to the memorymanipulation operation(s) sent to each machine, this embodiment morereadily enables the modification carried out by each machine to beslightly different and to be enhanced, customized, and/or optimizedbased upon its particular machine architecture, hardware, processor,memory, configuration, operating system, or other factors, yet stillsimilar, coherent and consistent with other machines with all othersimilar modifications and characteristics that may not need to besimilar or identical.

In all of the described instances or embodiments, the supply or thecommunication of the asset code (such as class code or object code) tothe machines M1, . . . , Mn, and optionally inclusive of a machine X ofFIG. 15, can be branched, distributed or communicated among and betweenthe different machines in any combination or permutation; such as byproviding direct machine to machine communication (for example, M2supplies each of M1, M3, M4, etc. directly), or by providing or usingcascaded or sequential communication (for example, M2 supplies M1 whichthen supplies M3 which then supplies M4, and so on), or a combination ofthe direct and cascaded and/or sequential.

Reference is made to the accompanying Annexure A in which: Annexure A5is a typical code fragment from a memory manipulation operation prior tomodification (e.g., an exemplary unmodified routine with a memorymanipulation operation), and Annexure A6 is the same routine with amemory manipulation operation after modification (e.g., an exemplarymodified routine with a memory manipulation operation). These codefragments are exemplary only and identify one software code means forperforming the modification in an exemplary language. It will beappreciated that other software/firmware or computer program code may beused to accomplish the same or analogous function or operation withoutdeparting from the invention.

Annexures A5 and A6 (also reproduced in part in Table VI and Table VIIbelow) are exemplary code listings that set forth the conventional orunmodified computer program software code (such as may be used in asingle machine or computer environment) of a routine with a memorymanipulation operation of application program code 50 and apost-modification excerpt of the same routine such as may be used inembodiments of the present invention having multiple machines. Themodified code that is added to the routine is highlighted in bold text.

TABLE I Summary Listing of Contents of Annexure A Annexure A includesexemplary program listings in the JAVA language to further illustratefeatures, aspects, methods, and procedures of described in the detaileddescription A1. This first excerpt is part of an illustration of themodification code of the modifier 51 in accordance with steps 92 and 103of FIG. 10. It searches through the code array of the applicationprogram code 50, and when it detects a memory manipulation instruction(i.e. a putstatic instruction (opcode 178) in the JAVA language andvirtual machine environment) it modifies the application program code bythe insertion of an “alert” routine. A2. This second excerpt is part ofthe DRT.alert ( ) method and implements the step of 125 and arrow of 127of FIG. 12. This DRT.alert ( ) method requests one or more threads ofthe DRT processing environment of FIG. 12 to update and propagate thevalue and identity of the changed memory location corresponding to theoperation of Annexure A1. A3. This third excerpt is part of the DRT 71,and corresponds to step 128 of FIG. 12. This code fragment shows the DRTin a separate thread, such as thread 121/1 of FIG. 12, after beingnotified or requested by step 125 and array 127, and sending the changedvalue and changed value location/identity across the network 53 to theother of the plurality of machines M1 . . . Mn. A4. The fourth excerptis part of the DRT 71, and corresponds to steps 135 and 136 of FIG. 13.This is a fragment of code to receive a propagated identity and valuepair sent by another DRT 71 over the network, and write the changedvalue to the identified memory location. A5. The fifth excerpt is andisassembled compiled form of the example.java application of AnnexureA7, which performs a memory manipulation operation (putstatic andputfield). A6. The sixth excerpt is the disassembled compiled form ofthe same example application in Annexure A5 after modification has beenperformed by FieldLoader.java of Annexure A11, in accordance with FIG. 9of this invention. The modifications are highlighted in bold. A7. Theseventh excerpt is the source-code of the example.java application usedin excerpt A5 and A6. This example application has two memory locations(staticValue and instanceValue) and performs two memory manipulationoperations. A8. The eighth excerpt is the source-code of FieldAlert.javawhich corresponds to step 125 and arrow 127 of FIG. 12, and whichrequests a thread 121/1 executing FieldSend.java of the “distributedrun-time” 71 to propagate a changed value and identity pair to the othermachines M1 . . . Mn. A9. The ninth excerpt is the source-code ofFieldSend.java which corresponds to step 128 of FIG. 12, and waits for arequest/notification generated by FieldAlert.java of A8 corresponding tostep 125 and arrow 127, and which propagates a changed value/identitypair requested of it by FieldAlert.java, via network 53. A10. The tenthexcerpt is the source-code of FieldReceive.java, which corresponds tosteps 135 and 136 of FIG. 13, and which receives a propagated changedvalue and identity pair sent to it over the network 53 viaFieldSend.java of annexure A9. A11. FieldLoader.java. This excerpt isthe source-code of FieldLoader.java, which modifies an applicationprogram code, such as the example.java application code of Annexure A7,as it is being loaded into a JAVA virtual machine in accordance withsteps 90, 91, 92, 103, and 94 of FIG. 10. FieldLoader.java makes use ofthe convenience classes of Annexures A12 through to A36 during themodification of a compiled JAVA A12. Attribute_info.java Convience classfor representing attribute_info structures within ClassFiles. A13.ClassFile.java Convience class for representing ClassFile structures.A14. Code_attribute.java Convience class for representing Code_attributestructures within ClassFiles. A15. CONSTANT_Class_info.java Convienceclass for representing CONSTANT_Class_info structures within ClassFiles.A16. CONSTANT_Double_info.java Convience class for representingCONSTANT_Double_info structures within ClassFiles. A17.CONSTANT_Fieldref_info.java Convience class for representingCONSTANT_Fieldref_info structures within ClassFiles. A18.CONSTANT_Float_info.java Convience class for representingCONSTANT_Float_info structures within ClassFiles. A19.CONSTANT_Integer_info.java Convience class for representingCONSTANT_Integer_info structures within ClassFiles. A20.CONSTANT_InterfaceMethodref_info.java Convience class for representingCONSTANT_InterfaceMethodref_info structures within ClassFiles. A21.CONSTANT_Long_info.java Convience class for representingCONSTANT_Long_info structures within ClassFiles. A22.CONSTANT_Methodref_info.java Convience class for representingCONSTANT_Methodref_info structures within ClassFiles. A23.CONSTANT_NameAndType_info.java Convience class for representingCONSTANT_NameAndType_info structures within ClassFiles. A24.CONSTANT_String_info.java Convience class for representingCONSTANT_String_info structures within ClassFiles. A25.CONSTANT_Utf8_info.java Convience class for representingCONSTANT_Utf8_info structures within ClassFiles. A26.ConstantValue_attribute.java Convience class for representingConstantValue_attribute structures within ClassFiles. A27. cp_info.javaConvience class for representing cp_info structures within ClassFiles.A28. Deprecated_attribute.java Convience class for representingDeprecated_attribute structures within ClassFiles. A29.Exceptions_attribute.java Convience class for representingExceptions_attribute structures within ClassFiles. A30. field_info.javaConvience class for representing field_info structures withinClassFiles. A31. InnerClasses_attribute.java Convience class forrepresenting InnerClasses_attribute structures within ClassFiles. A32.LineNumberTable_attribute.java Convience class for representingLineNumberTable_attribute structures within ClassFiles. A33.LocalVariableTable_attribute.java Convience class for representingLocalVariableTable_attribute structures within ClassFiles. A34.method_info.java Convience class for representing method_info structureswithin ClassFiles. A35. SourceFile_attribute.java Convience class forrepresenting SourceFile_attribute structures within ClassFiles. A36.Synthetic_attribute.java Convience class for representingSynthetic_attribute structures within ClassFiles.

TABLE II Exemplary code listing showing embodiment of modified code. A1.This first excerpt is part of an illustration of the modification codeof the modifier 51 in accordance with steps 92 and 103 of FIG. 10. Itsearches through the code array of the application program code 50, andwhen it detects a memory manipulation instruction (i.e. a putstaticinstruction (opcode 178) in the JAVA language and virtual machineenvironment) it modifies the application program code by the insertionof an “alert” routine. // START byte[ ] code = Code_attribute.code; //Bytecode of a given method in a // given classfile. int code_length =Code_attribute.code_length; int DRT = 99; // Location of theCONSTANT_Methodref_info for the // DRT.alert( ) method. for (int i=0;i<code_length; i++){  if ((code[i] & 0xff) == 179){ // Putstaticinstruction.   System.arraycopy(code, i+3, code, i+6,code_length−(i+3));   code[i+3] = (byte) 184; // Invokestaticinstruction for the // DRT.alert( ) method.   code[i+4] = (byte)((DRT >>> 8) & 0xff);   code[i+5] = (byte) (DRT & 0xff);  } } // END

TABLE III Exemplary code listing showing embodiment of code for alertmethod A2. This second excerpt is part of the DRT.alert( ) method andimplements the step of 125 and arrow of 127 of FIG. 12. This DRT.alert() method requests one or more threads of the DRT processing environmentof FIG. 12 to update and propagate the value and identity of the changedmemory location corresponding to the operation of Annexure A1. // STARTpublic static void alert( ){  synchronized (ALERT_LOCK){  ALERT_LOCK.notify( ); // Alerts a waiting DRT thread   in thebackground.  } } // END

TABLE IV Exemplary code listing showing embodiment of code for DRT A3.This third excerpt is part of the DRT 71, and corresponds to step 128 ofFIG. 12. This code fragment shows the DRT in a separate thread, such asthread 121/1 of FIG. 12, after being notified or requested by step 125and array 127, and sending the changed value and changed valuelocation/identity across the network 53 to the other of the plurality ofmachines M1 . . . Mn. // START MulticastSocket ms =DRT.getMulticastSocket( ); // The multicast socket // used by the DRTfor // communication. byte nameTag = 33; // This is the “name tag” onthe network for this // field. Field field =modifiedClass.getDeclaredField(“myField1”); // Stores // the field //from the // modified // class. // In this example, the field is a bytefield. while (DRT.isRunning( )){  synchronized (ALERT_LOCK){  ALERT_LOCK.wait( ); // The DRT thread is waiting // for the alertmethod to be called.   byte[ ] b = new byte[ ]{nameTag,field.getByte(null)}; // Stores // the // nameTag // and the // value //of the // field from // the // modified // class in a buffer.  DatagramPacket dp = new DatagramPacket(b, 0, b.length);   ms.send(dp); // Send the buffer out across the network.  } } // END

TABLE V Exemplary code listing showing embodiment of code for DRTreceiving. A4. The fourth excerpt is part of the DRT 71, and correspondsto steps 135 and 136 of FIG. 13. This is a fragment of code to receive apropagated identity and value pair sent by another DRT 71 over thenetwork, and write the changed value to the identified memory location.// START MulticastSocket ms = DRT.getMulticastSocket( ); // Themulticast socket // used by the DRT for // communication. DatagramPacketdp = new DatagramPacket(new byte[2], 0, 2); byte nameTag = 33; // Thisis the “name tag” on the network for this // field. Field field =modifiedClass.getDeclaredField(“myField1”); // Stores the // field from// the // modified class. // In this example, the field is a byte field.while (DRT.isRunning){  ms.receive(dp);  // Receive the previously sentbuffer from the  network.  byte[ ] b = dp.getData( );  if (b[0] ==nameTag){ // Check the nametags match.   field.setByte(null, b[1]); //Write the value from the network packet // into the field location inmemory.  } } // END

TABLE VI Exemplary code listing showing embodiment of application beforemodification is made. A5. The fifth excerpt is an disassembled compiledform of the example.java application of Annexure A7, which performs amemory manipulation operation (putstatic and putfield). Method voidsetValues(int, int)  0 iload_1  1 putstatic #3 <Field int staticValue> 4 aload_0  5 iload_2  6 putfield #2 <Field int instanceValue>  9 return

TABLE VII Exemplary code listing showing embodiment of application aftermodification is made. A6. The sixth excerpt is the disassembled compiledform of the same example application in Annexure A5 after modificationhas been performed by FieldLoader.java of Annexure A11, in accordancewith FIG. 9 of this invention. The modifications are highlighted inbold. Method void setValues(int, int)  0 iload_1  1 putstatic #3 <Fieldint staticValue>  4 ldc #4 <String “example”>  6 iconst — 0  7invokestatic #5 <Method void alert(java.lang.Object, int)>   10 aload_0  11 iload_2   12 putfield #2 <Field int instanceValue>   15 aload — 0  16 iconst — 1   17 invokestatic #5 <Method voidalert(java.lang.Object, int)>   20 return

TABLE VIII Exemplary code listing showing embodiment of source-code ofthe example application. A7. The seventh excerpt is the source-code ofthe example.java application used in excerpt A5 and A6. This exampleapplication has two memory locations (staticValue and instanceValue) andperforms two memory manipulation operations. import java.lang.*; publicclass example{  /** Shared static field. */  public static intstaticValue = 0;  /** Shared instance field. */  public intinstanceValue = 0;  /** Example method that writes to memory (instancefield). */  public void setValues(int a, int b){   staticValue = a;  instanceValue = b;  } }

TABLE IX Exemplary code listing showing embodiment of the source-code ofFieldAlert. A8. The eighth excerpt is the source-code of FieldAlert.javawhich corresponds to step 125 and arrow 127 of FIG. 12, and whichrequests a thread 121/1 executing FieldSend.java of the “distributedrun-time” 71 to propagate a changed value and identity pair to the othermachines M1 . . . Mn. import java.lang.*; import java.util.*; importjava.net.*; import java.io.*; public class FieldAlert{  /** Table ofalerts. */  public final static Hashtable alerts = new Hashtable( ); /** Object handle. */  public Object reference = null;  /** Table offield alerts for this object. */  public boolean[ ] fieldAlerts = null; /** Constructor. */  public FieldAlert(Object o, intinitialFieldCount){   reference = o;   fieldAlerts = newboolean[initialFieldCount];  }  /** Called when an application modifiesa value. (Both objects and    classes) */  public static voidalert(Object o, int fieldID){   // Lock the alerts table.   synchronized(alerts){    FieldAlert alert = (FieldAlert) alerts.get(o);    if (alert== null){ // This object hasn't been alerted already, // so add toalerts table.     alert = new FieldAlert(o, fieldID + 1);    alerts.put(o, alert);    }    if (fieldID >=alert.fieldAlerts.length){     // Ok, enlarge fieldAlerts array.    boolean[ ] b = new boolean[fieldID+1];    System.arraycopy(alert.fieldAlerts, 0, b, 0,     alert.fieldAlerts.length);     alert.fieldAlerts = b;    }    //Record the alert.    alert.fieldAlerts[fieldID] = true;    // Mark aspending.    FieldSend.pending = true; // Signal that there is one ormore // propagations waiting.    // Finally, notify the waitingFieldSend thread(s)    if (FieldSend.waiting){     FieldSend.waiting =false;     alerts.notify( );    }   }  } }

It is noted that the compiled code in the annexure and portion repeatedin the table is taken from the source-code of the file “example.java”which is included in the Annexure A7 (Table VIII). In the procedure ofAnnexure A5 and Table VI, the procedure name “Method void setValues(int,int)” of Step 001 is the name of the displayed disassembled output ofthe setValues method of the compiled application code of “example.java”.The name “Method void setValues(int, int)” is arbitrary and selected forthis example to indicate a typical JAVA method inclusive of a memorymanipulation operation. Overall the method is responsible for writingtwo values to two different memory locations through the use of a memorymanipulation assignment statement (being “putstatic” and “putfield” inthis example) and the steps to accomplish this are described in turn.

First (Step 002), the Java Virtual Machine instruction “iload_(—)1”causes the Java Virtual Machine to load the integer value in the localvariable array at index 1 of the current method frame and store thisitem on the top of the stack of the current method frame and results inthe integer value passed to this method as the first argument and storedin the local variable array at index 1 being pushed onto the stack.

The Java Virtual Machine instruction “putstatic #3<Field intstaticValue>” (Step 003) causes the Java Virtual Machine to pop thetopmost value off the stack of the current method frame and store thevalue in the static field indicated by the CONSTANT_Fieldref_infoconstant-pool item stored in the 3^(rd) index of the classfile structureof the application program containing this example setValues( ) methodand results in the topmost integer value of the stack of the currentmethod frame being stored in the integer field named “staticValue”.

The Java Virtual Machine instruction “aload_(—)0” (Step 004) causes theJava Virtual Machine to load the item in the local variable array atindex 0 of the current method frame and store this item on the top ofthe stack of the current method frame and results in the ‘this’ objectreference stored in the local variable array at index 0 being pushedonto the stack.

First (Step 005), the Java Virtual Machine instruction “iload_(—)2”causes the Java Virtual Machine to load the integer value in the localvariable array at index 2 of the current method frame and store thisitem on the top of the stack of the current method frame and results inthe integer value passed to this method as the first argument and storedin the local variable array at index 2 being pushed onto the stack.

The Java Virtual Machine instruction “putfield #2<Field intinstanceValue>” (Step 006) causes the Java Virtual Machine to pop thetwo topmost values off the stack of the current method frame and storethe topmost value in the object instance field of the second poppedvalue, indicated by the CONSTANT_Fieldref_info constant-pool item storedin the 2^(nd) index of the classfile structure of the applicationprogram containing this example setValues method and results in theinteger value on the top of the stack of the current method frame beingstored in the instance field named “instanceValue” of the objectreference below the integer value on the stack.

Finally, the JAVA virtual machine instruction “return” (Step 007) causesthe JAVA virtual machine to cease executing this setValues( ) method byreturning control to the previous method frame and results intermination of execution of this setValues( ) method.

As a result of these steps operating on a single machine of theconventional configurations in FIG. 1 and FIG. 2, the JAVA virtualmachine manipulates (i.e. writes to) the staticValue and instanceValuememory locations, and in executing the setValues( ) method containingthe memory manipulation operation(s) is able to ensure that memory isand remains consistent between multiple threads of a single applicationinstance, and therefore ensure that unwanted behaviour, such as forexample inconsistent or incoherent memory between multiple threads of asingle application instance (such inconsistent or incoherent memorybeing for example incorrect or different values or contents with respectto a single memory location) does not occur. Were these steps to becarried out on the plurality of machines of the configurations of FIG. 5and FIG. 8 by concurrently executing the application program code 50 oneach one of the plurality of machines M1 . . . Mn, the memorymanipulation operations of each concurrently executing applicationprogram occurrence on each one of the machines would be performedwithout coordination between any other machine(s), such coordinationbeing for example updating of corresponding memory locations on eachmachine such that they each report a same content or value. Given thedesirable result of consistent, coordinated and coherent memory stateand manipulation and updating operation across a plurality of amachines, this prior art arrangement would fail to perform suchconsistent, coherent, and coordinated memory state and manipulation andupdating operation across the plurality of machines, as each machineperforms memory manipulation only locally and without any attempt tocoordinate or update their local memory state and manipulation operationwith any other similar memory state on any one or more other machines.Such an arrangement would therefore be susceptible to inconsistent andincoherent memory state amongst machines M1 . . . Mn due touncoordinated, inconsistent and/or incoherent memory manipulation andupdating operation. Therefore it is desirable to overcome thislimitation of the prior art arrangement.

In the exemplary code in Table VII (Annexure A6), the code has beenmodified so that it solves the problem of consistent, coordinated memorymanipulation and updating operation for a plurality of machines M1 . . .Mn, that was not solved in the code example from Table VI (Annexure A5).In this modified setValues( ) method code, an “ldc #4 <String“example”>” instruction is inserted after the “putstatic #3” instructionin order to be the first instruction following the execution of the“putstatic #3” instruction. This causes the JAVA virtual machine to loadthe String value “example” onto the stack of the current method frameand results in the String value of “example” loaded onto the top of thestack of the current method frame. This change is significant because itmodifies the setValues( ) method to load a String identifiercorresponding to the classname of the class containing the static fieldlocation written to by the “putstatic #3” instruction onto the stack.

Furthermore, the JAVA virtual machine instruction “iconst_(—)0” isinserted after the “ldc #4” instruction so that the JAVA virtual machineloads an integer value of “0” onto the stack of the current method frameand results in the integer value of “0” loaded onto the top of the stackof the current method frame. This change is significant because itmodifies the setValues( ) method to load an integer value, which in thisexample is “0”, which represents the identity of the memory location(field) manipulated by the preceding “putstatic #3” operation. It is tobe noted that the choice or particular form of the memory identifierused for the implementation of this invention is for illustrationpurposes only. In this example, the integer value of “0” is theidentifier used of the manipulated memory location, and corresponds tothe “staticValue” field as the first field of the “example.java”application, as shown in Annexure A7. Therefore, corresponding to the“putstatic #3” instruction, the “iconst_(—)0” instruction loads theinteger value “0” corresponding to the index of the manipulated field ofthe “putstatic #3” instruction, and which in this case is the firstfield of “example.java” hence the “0” integer index value, onto thestack.

Additionally, the JAVA virtual machine instruction “invokestatic#5<Method boolean alert(java.lang.Object, int)>” is inserted after the“iconst_(—)0” instruction so that the JAVA virtual machine pops the twotopmost items off the stack of the current method frame (which inaccordance with the preceding “ldc #4” instruction is a reference to theString object with the value “example” corresponding to the name of theclass to which manipulated field belongs, and the integer “0”corresponding to the index of the manipulated field in the example.javaapplication) and invokes the “alert” method, passing the two topmostitems popped off the stack to the new method frame as its first twoarguments. This change is significant because it modifies the setValues() method to execute the “alert” method and associated operations,corresponding to the preceding memory manipulation operation (that is,the “putstatic #3” instruction) of the setValues( ) method.

Likewise, in this modified setValues( ) method code, an “aload_(—)0”instruction is inserted after the “putfield #2” instruction in order tobe the first instruction following the execution of the “putfield #2”instruction. This causes the JAVA virtual machine to load the instanceobject of the example class to which the manipulated field of thepreceding “putfield #2” instruction belongs, onto the stack of thecurrent method frame and results in the object reference correspondingto the instance field written to by the “putfield #2” instruction,loaded onto the top of the stack of the current method frame. Thischange is significant because it modifies the setValues( ) method toload a reference to the object corresponding to the manipulated fieldonto the stack.

Furthermore, the JAVA virtual machine instruction “iconst_(—)1” isinserted after the “aload_(—)0” instruction so that the JAVA virtualmachine loads an integer value of “1” onto the stack of the currentmethod frame and results in the integer value of “1” loaded onto the topof the stack of the current method frame. This change is significantbecause it modifies the setValues( ) method to load an integer value,which in this example is “1”, which represents the identity of thememory location (field) manipulated by the preceding “putfield #2”operation. It is to be noted that the choice or particular form of theidentifier used for the implementation of this invention is forillustration purposes only. In this example, the integer value of “1”corresponds to the “instanceValue” field as the second field of the“example.java” application, as shown in Annexure A7. Therefore,corresponding to the “putfield #2” instruction, the “iconst_(—)1”instruction loads the integer value “1” corresponding to the index ofthe manipulated field of the “putfield #2” instruction, and which inthis case is the second field of “example.java” hence the “1” integerindex value, onto the stack.

Additionally, the JAVA virtual machine instruction “invokestatic#5<Method boolean alert(java.lang.Object, int)>” is inserted after the“iconst_(—)1” instruction so that the JAVA virtual machine pops the twotopmost item off the stack of the current method frame (which inaccordance with the preceding “aload_(—)0”.instruction is a reference tothe object corresponding to the object to which the manipulated instancefield belongs, and the integer “1” corresponding to the index of themanipulated field in the example.java application) and invokes the“alert” method, passing the two topmost items popped off the stack tothe new method frame as its first two arguments. This change issignificant because it modifies the setValues( ) method to execute the“alert” method and associated operations, corresponding to the precedingmemory manipulation operation (that is, the “putfield #2” instruction)of the setValues( ) method.

The method void alert(java.lang.Object, int), part of the FieldAlertcode of Annexure A8 and part of the distributed runtime system (DRT) 71,requests or otherwise notifies a DRT thread 121/1 executing theFieldSend.java code of Annexure A9 to update and propagate the changedidentity and value of the manipulated memory location to the pluralityof machines M1 . . . Mn.

It will be appreciated that the modified code permits, in a distributedcomputing environment having a plurality of computers or computingmachines, the coordinated operation of memory manipulation operations sothat the problems associated with the operation of the unmodified codeor procedure on a plurality of machines M1 . . . Mn (such as for exampleinconsistent and incoherent memory state and manipulation and updatingoperation) does not occur when applying the modified code or procedure.

Initialization

Returning again to FIG. 14, there is illustrated a schematicrepresentation of a single prior art computer operated as a JAVA virtualmachine. In this way, a machine (produced by any one of variousmanufacturers and having an operating system operating in any one ofvarious different languages) can operate in the particular language ofthe application program code 50, in this instance the JAVA language.That is, a JAVA virtual machine 72 is able to operate application code50 in the JAVA language, and utilize the JAVA architecture irrespectiveof the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment,the generalized platform, and/or virtual machine and/or machine and/orruntime system is able to operate application code 50 in the language(s)(possibly including for example, but not limited to any one or more ofsource-code languages, intermediate-code languages, object-codelanguages, machine-code languages, and any other code languages) of thatplatform, and/or virtual machine and/or machine and/or runtime systemenvironment, and utilize the platform, and/or virtual machine and/ormachine and/or runtime system and/or language architecture irrespectiveof the machine manufacturer and the internal details of the machine. Itwill also be appreciated in light of the description provided hereinthat the platform and/or runtime system may include virtual machine andnon-virtual machine software and/or firmware architectures, as well ashardware and direct hardware coded applications and implementations.

Returning to the example of the JAVA language virtual machineenvironment, in the JAVA language, the class initialization routine<clinit> happens only once when a given class file 50A is loaded.However, the object initialization routine <init> typically happensfrequently, for example the object initialization routine may usuallyoccur every time a new object (such as an object 50X, 50Y or 50Z) iscreated. In addition, within the JAVA environment and other machine orother runtime system environments using classes and object constructs,classes (generally being a broader category than objects) are loadedprior to objects (which are the narrower category and wherein theobjects belong to or are identified with a particular class) so that inthe application code 50 illustrated in FIG. 14, having a single class50A and three objects 50X, 50Y, and 50Z, the first class 50A is loadedfirst, then first object 50X is loaded, then second object 50Y is loadedand finally third object 50Z is loaded.

Where, as in the embodiment illustrated relative to FIG. 14, there isonly a single computer or machine 72 (and not a plurality of connectedor coupled computers or machines), then no conflict or inconsistencyarises in the running of the initialization routines (such as class andobject initialization routines) intended to operate during the loadingprocedure because for conventional operation each initialization routineis executed only once by the single virtual machine or machine orruntime system or language environment as needed for each of the one ormore classes and one or more objects belonging to or identified with theclasses, or equivalent where the terms classes and object are not used.

For a more general set of virtual machine or abstract machineenvironments, and for current and future computers and/or computingmachines and/or information appliances or processing systems, and thatmay not utilize or require utilization of either classes and/or objects,the inventive structure, method, and computer program and computerprogram product are still applicable. Examples of computers and/orcomputing machines that do not utilize either classes and/or objectsinclude for example, the x86 computer architecture manufactured by IntelCorporation and others, the SPARC computer architecture manufactured bySun Microsystems, Inc and others, the PowerPC computer architecturemanufactured by International Business Machines Corporation and others,and the personal computer products made by Apple Computer, Inc., andothers. For these types of computers, computing machines, informationappliances, and the virtual machine or virtual computing environmentsimplemented thereon that do not utilize the idea of classes or objects,the terms ‘class’ and ‘object’ may be generalized for example to includeprimitive data types (such as integer data types, floating point datatypes, long data types, double data types, string data types, characterdata types and boolean data types), structured data types (such asarrays and records) derived types, or other code or data structures ofprocedural languages or other languages and environments such asfunctions, pointers, components, modules, structures, references andunions.

Returning to the example of the JAVA language virtual machineenvironment, in the JAVA language, the class initialization routine<clinit> happens only once when a given class file 50A is loaded.However, the object initialization routine <init> typically happensfrequently, for example the object initialisation routine will occurevery time a new object (such as an object 50X, 50Y and 50Z) is created.In addition, within the JAVA environment and other machine or otherruntime system environments using classes and object constructures,classes (being the broader category) are loaded prior to objects (whichare the narrower category and wherein the objects belong to or areidentified with a particular class) so that in the application code 50illustrated in FIG. 14, having a single class 50A and three objects50X-50Z, the first class 50A is loaded first, then the first object 50Xis loaded, then second object 50Y is loaded and finally third object 50Zis loaded.

Where, as in the embodiment illustrated relative to FIG. 14, there isonly a single computer or machine 72 (not a plurality of connected orcoupled machines), then no conflict or inconsistency arises in therunning of the initialization routines (i.e. the class initializationroutine <clinit> and the object initialisation routine <init>) intendedto operate during the loading procedure because for conventionaloperation each initialisation routine is executed only once by thesingle virtual machine or machine or runtime system or languageenvironment as needed for each of the one or more classes and one ormore objects belonging to or identified with the classes.

However, in the arrangement illustrated in FIG. 8, (and also in FIGS.31-33), a plurality of individual computers or machines M1, M2, . . . ,Mn are provided, each of which are interconnected via a communicationsnetwork 53 or other communications link and each of which individualcomputers or machines provided with a modifier 51 (See in FIG. 5) andrealised by or in for example the distributed runtime system(DRT) 71(See FIG. 8) and loaded with a common application code 50. The termcommon application program is to be understood to mean an applicationprogram or application program code written to operate on a singlemachine, and loaded and/or executed in whole or in part on each one ofthe plurality of computers or machines M1, M2 . . . Mn, or optionally oneach one of some subset of the plurality of computers or machines M1, M2. . . Mn. Put somewhat differently, there is a common applicationprogram represented in application code 50, and this single copy orperhaps a plurality of identical copies are modified to generate amodified copy or version of the application program or program code,each copy or instance prepared for execution on the plurality ofmachines. At the point after they are modified they are common in thesense that they perform similar operations and operate consistently andcoherently with each other. It will be appreciated that a plurality ofcomputers, machines, information appliances, or the like implementingthe features of the invention may optionally be connected to or coupledwith other computers, machines, information appliances, or the like thatdo not implement the features of the invention.

In some embodiments, some or all of the plurality of individualcomputers or machines may be contained within a single housing orchassis (such as so-called “blade servers” manufactured byHewlett-Packard Development Company, Intel Corporation, IBM Corporationand others) or implemented on a single printed circuit board or evenwithin a single chip or chip set.

Essentially the modifier 51 or DRT 71 or other code modifying means isresponsible for modifying the application code 50 so that it may executeinitialisation routines or other initialization operations, such as forexample class and object initialization methods or routines in the JAVAlanguage and virtual machine environment, in a coordinated, coherent,and consistent manner across and between the plurality of individualmachines M1, M2 . . . Mn. It follows therefore that in such a computingenvironment it is necessary to ensure that the local objects and classeson each of the individual machines M1, M2 . . . Mn is initialized in aconsistent fashion (with respect to the others).

It will be appreciated in light of the description provided herein thatthere are alternative implementations of the modifier 51 and thedistributed run time 71. For example, the modifier 51 may be implementedas a component of or within the distributed run time 71, and thereforethe DRT 71 may implement the functions and operations of the modifier51. Alternatively, the function and operation of the modifier 51 may beimplemented outside of the structure, software, firmware, or other meansused to implement the DRT 71. In one embodiment, the modifier 51 and DRT71 are implemented or written in a single piece of computer program codethat provides the functions of the DRT and modifier. The modifierfunction and structure therefore maybe subsumed into the DRT andconsidered to be an optional component. Independent of how implemented,the modifier function and structure is responsible for modifying theexecutable code of the application code program, and the distributed runtime function and structure is responsible for implementingcommunications between and among the computers or machines. Thecommunications functionality in one embodiment is implemented via anintermediary protocol layer within the computer program code of the DRTon each machine. The DRT may for example implement a communicationsstack in the JAVA language and use the Transmission ControlProtocol/Internet Protocol (TCP/IP) to provide for communications ortalking between the machines. Exactly how these functions or operationsare implemented or divided between structural and/or proceduralelements, or between computer program code or data structures within theinvention are less important than that they are provided.

In order to ensure consistent class and object (or equivalent)initialisation status and initialisation operation between and amongstmachines M1, M2, . . . , Mn, the application code 50 is analysed orscrutinized by searching through the executable application code 50 inorder to detect program steps (such as particular instructions orinstruction types) in the application code 50 which define or constituteor otherwise represent an initialization operation or routine (or othersimilar memory, resource, data, or code initialization routine oroperation). In the JAVA language, such program steps may for examplecomprise or consist of some part of, or all of, a “<init>” or “<clinit>”method of an object or class, and optionally any other code, routine, ormethod related to a “<init>” or “<clinit>” method, for example by meansof a method invocation from the body of the “<init>” of “<clinit>”method to a different method.

This analysis or scrutiny of the application code 50 may take placeeither prior to loading the application program code 50, or during theapplication program code 50 loading procedure, or even after theapplication program code 50 loading procedure. It may be likened to aninstrumentation, program transformation, translation, or compilationprocedure in that the application code may be instrumented withadditional instructions, and/or otherwise modified by meaning-preservingprogram manipulations, and/or optionally translated from an input codelanguage to a different code language (such as for example fromsource-code language or intermediate-code language to object-codelanguage or machine-code language), and with the understanding that theterm compilation normally or conventionally involves a change in code orlanguage, for example, from source code to object code or from onelanguage to another language. However, in the present instance the term“compilation” (and its grammatical equivalents) is not so restricted andcan also include or embrace modifications within the same code orlanguage. For example, the compilation and its equivalents areunderstood to encompass both ordinary compilation (such as for exampleby way of illustration but not limitation, from source-code toobject-code), and compilation from source-code to source-code, as wellas compilation from object-code to object-code, and any alteredcombinations therein. It is also inclusive of so-called“intermediary-code languages” which are a form of “pseudo object-code”.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 may take place duringthe loading of the application program code such as by the operatingsystem reading the application code from the hard disk or other storagedevice or source and copying it into memory and preparing to beginexecution of the application program code. In another embodiment, in aJAVA virtual machine, the analysis or scrutiny may take place during theclass loading procedure of the java.lang.ClassLoader loadClass method(e.g., “java.lang.ClassLoader.loadClass( )”).

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading procedure,such as after the operating system has loaded the application code intomemory, or optionally even after execution of the application programcode has started or commenced, such as for example after the JAVAvirtual machine has loaded the application code into the virtual machinevia the “java.lang.ClassLoader.loadClass( )” method and optionallycommenced execution.

As a consequence, of the above described analysis or scrutiny,initialization routines (for example <clinit> class initialisationmethods and <init> object initialization methods) are initially lookedfor, and when found or identified a modifying code is inserted, so as togive rise to a modified initialization routine. This modified routine isadapted and written to initialize the class 50A on one of the machines,for example JVM#1, and tell, notify, or otherwise communicate to all theother machines M2, . . . , Mn that such a class 50A exists andoptionally its initialized state. There are several differentalternative modes wherein this modification and loading can be carriedout.

Thus, in one mode, the DRT 71/1 on the loading machine, in this exampleJava Virtual Machine M1 (JVM#1), asks the DRT's 71/2 . . . 71/n of allthe other machines M1, . . . Mn if the similar equivalent first class50A is initialized (i.e. has already been initialized) on any othermachine. If the answer to this question is yes (that is, a similarequivalent class 50A has already been initialized on another machine),then the execution of the initialization procedure is aborted, paused,terminated, turned off or otherwise disabled for the class 50A onmachine JVM#1. If the answer is no (that is, a similar equivalent class50A has not already been initialised on another machine), then theinitialization operation is continued (or resumed, or started, orcommenced and the class 50A is initialized and optionally theconsequential changes (such as for example initialized code anddata-structures in memory) brought about during that initializationprocedure are transferred to each similar equivalent local class on eachone of the other machines as indicated by arrows 83 in FIG. 8.

A similar procedure happens on each occasion that an object, say 50X,50Y or 50Z is to be loaded and initialized. Where the DRT 71/1 of theloading machine, in this example Java Machine M1 (JVM#1), does notdiscern, as a result of interrogation of the other machines M2 . . . Mnthat, a similar equivalent object to the particular object to beinitialized on machine M1, say object 50Y, has already been initialisedby another machine, then the DRT 71/1 on machine M1 may execute theobject initialization routine corresponding to object 50Y, andoptionally each of the other machines M2 . . . Mn may load a similarequivalent local object (which may conveniently be termed a peer object)and associated consequential changes (such as for example initializeddata, initialized code, and/or initialized system or resourcesstructures) brought about by the execution of the initializationoperation on machine M1 However, if the DRT 71/1 of machine M1determines that a similar equivalent object to the object SOY inquestion has already been initialization on another machine of theplurality of machines (say for example machine M2), then the executionby machine M1 of the initialization function, procedure, or routinecorresponding to object SOY is not started or commenced, or is otherwiseaborted, terminated, turned off or otherwise disabled, and object SOY onmachine M1 is loaded, and preferably but optionally the consequentialchanges (such as for example initialized data, initialized code, and/orother initialized system or resource structures) brought about by theexecution of the initialization routine by machine M2, is loaded onmachine M1 corresponding to object 50Y. Again there are various ways ofbringing about the desired result.

Preferably, execution of the initialization routine is allocated to onemachine, such as the first machine M1 to load (and optionally seek toinitialize) the object or class. The execution of the initializationroutine corresponding to the determination that a particular class orobject (and any similar equivalent local classes or objects on each ofthe machines M1 . . . Mn) is not already initialized, is to execute onlyonce with respect to all machines M1 . . . Mn, and preferably by onlyone machine, on behalf of all machines M1 . . . Mn. Corresponding to,and preferably following, the execution of the initialization routine byone machine (say machine M1), all other machines may then each load asimilar equivalent local object (or class) and optionally load theconsequential changes (such as for example initialized data, initializedcode, and/or other initialized system or resource structures) broughtabout by the execution of the initialization operation by machine M1.

As seen in FIG. 15 a modification to the general arrangement of FIG. 8is provided in that machines M1, M2 . . . Mn are as before and run thesame application code 50 (or codes) on all machines M1, M2 . . . Mnsimultaneously or concurrently. However, the previous arrangement ismodified by the provision of a server machine X which is convenientlyable to supply housekeeping functions, for example, and especially theinitialisation of structures, assets, and resources. Such a servermachine X can be a low value commodity computer such as a PC since itscomputational load is low. As indicated by broken lines in FIG. 15, twoserver machines X and X+1 can be provided for redundancy purposes toincrease the overall reliability of the system. Where two such servermachines X and X+1 are provided, they are preferably but optionallyoperated as redundant machines in a failover arrangement.

It is not necessary to provide a server machine X as its computationalload can be distributed over machines M1, M2 . . . Mn. Alternatively, adatabase operated by one machine (in a master/slave type operation) canbe used for the housekeeping function(s).

FIG. 16 shows a preferred general procedure to be followed. After aloading step 161 has been commenced, the instructions to be executed areconsidered in sequence and all initialization routines are detected asindicated in step 162. In the JAVA language these are the objectinitialisation methods (e.g. “<init>”) and class initialisation methods(e.g. “<clinit>”). Other languages use different terms.

Where an initialization routine is detected in step 162, it is modifiedin step 163 in order to perform consistent, coordinated, and coherentinitialization operation (such as for example initialization of datastructures and code structures) across and between the plurality ofmachines M1, M2 . . . Mn, typically by inserting further instructionsinto the initialisation routine to, for example, determine if a similarequivalent object or class (or other asset) on machines M1 . . . Mncorresponding to the object or class (or asset) to which thisinitialisation routine corresponds, has already been initialised, and ifso, aborting, pausing, terminating, turning off, or otherwise disablingthe execution of this initialization routine (and/or initializationoperation(s)), or if not then starting, continuing, or resuming theexecuting the initialization routine (and/or initializationoperation(s)), and optionally instructing the other machines M1 . . . Mnto load a similar equivalent object or class and consequential changesbrought about by the execution of the initialization routine.Alternatively, the modifying instructions may be inserted prior to theroutine, such as for example prior to the instruction(s) or operation(s)which commence initialization of the corresponding class or object. Oncethe modification step 163 has been completed the loading procedurecontinues by loading the modified application code in place of theunmodified application code, as indicated in step 164. Altogether, theinitialization routine is to be executed only once, and preferably byonly one machine, on behalf of all machines M1 . . . Mn corresponding tothe determination by all machines M1 . . . Mn that the particular objector class (i.e. the similar equivalent local object or class on eachmachine M1 . . . Mn corresponding to the particular object or class towhich this initialization routine relates) has not been initialized.

FIG. 17 illustrates a particular form of modification. After commencingthe routine in step 171, the structures, assets or resources (in JAVAtermed classes or objects) to be initialised are, in step 172, allocateda name or tag (for example a global name or tag) which can be used toidentify corresponding similar equivalent local objects on each of themachines M1, . . . , Mn. This is most conveniently done via a table (orsimilar data or record structure) maintained by server machine X of FIG.15. This table may also include an initialization status of the similarequivalent classes or object to be initialised. It will be understoodthat this table or other data structure may store only theinitialization status, or it may store other status or information aswell.

As indicated in FIG. 17, if steps 173 and 174 determine by means of thecommunication between machines M1 . . . Mn by DRT 71 that the similarequivalent local objects on each other machine corresponding to theglobal name or tag is not already initialised (i.e., not initialized ona machine other than the machine carrying out the loading and seeking toperform initialization), then this means that the object or class can beinitialised, preferably but optionally in the normal fashion, bystarting, commencing, continuing, or resuming the execution of, orotherwise executing, the initialization routine, as indicated in step176, since it is the first of the plurality of similar equivalent localobjects or classes of machines M1 . . . Mn to be initialized.

In one embodiment, the initialization routine is stopped from initiatingor commencing or beginning execution; however, in some implementationsit is difficult or practically impossible to stop the initializationroutine from initiating or beginning or commencing execution. Therefore,in an alternative embodiment, the execution of the initializationroutine that has already started or commenced is aborted such that itdoes not complete or does not complete in its normal manner. Thisalternative abortion is understood to include an actual abortion, or asuspend, or postpone, or pause of the execution of a initializationroutine that has started to execute (regardless of the stage ofexecution before completion) and therefore to make sure that theinitialization routine does not get the chance to execute to completionthe initialization of the object (or class or other asset)—and thereforethe object (or class or other asset) remains “un-initialized” (i.e.,“not initialized”).

However or alternatively, if steps 173 and 174 determine that the globalname corresponding to the plurality of similar equivalent local objectsor classes, each on a one of the plurality of machines M1 . . . Mn, isalready initialised on another machine, then this means that the objector class is considered to be initialized on behalf of, and for thepurposes of, the plurality of machines M1 . . . Mn. As a consequence,the execution of the initialisation routine is aborted, terminated,turned off, or otherwise disabled, by carrying out step 175.

FIG. 18, illustrative of one embodiment of step 173 of FIG. 17, showsthe inquiry made by the loading machine (one of M1, M2 . . . Mn) to theserver machine X of FIG. 15, to enquire as to the initialisation statusof the plurality of similar equivalent local objects (or classes)corresponding to the global name. The operation of the loading machineis temporarily interrupted as indicated by step 181, and correspondingto step 173 of FIG. 17, until a reply to this preceding request isreceived from machine X, as indicated by step 182. In step 181 theloading machine sends an inquiry message to machine X to request theinitialization status of the object (or class or other asset) to beinitialized. Next, the loading machine awaits a reply from machine Xcorresponding to the inquiry message sent by the proposing machine atstep 181, indicated by step 182.

FIG. 19 shows the activity carried out by machine X of FIG. 15 inresponse to such an initialization enquiry of step 181 of FIG. 18. Theinitialization status is determined in steps 192 and 193, whichdetermines if a similar equivalent object (or class or other asset)corresponding to the initialization status request of global name, asreceived at step 191, is initialized on another machine (i.e. a machineother than the enquiring machine 181 from which the initializationstatus request of step 191 originates), where a table of initialisationstates is consulted corresponding to the record for the global name and,if the initialisation status record indicates that a similar equivalentlocal object (or class) on another machine (such as on a one of themachines M1 . . . Mn) and corresponding to global name is alreadyinitialised, the response to that effect is sent to the enquiringmachine by carrying out step 194. Alternatively, if the initialisationstatus record indicates that a similar equivalent local object (orclass) on another machine (such as on a one of the plurality of machinesM1 . . . Mn) and corresponding to global name is uninitialized, acorresponding reply is sent to the enquiring machine by carrying outsteps 195 and 196. The singular term object or class as used here (orthe equivalent term of asset, or resource used in step 192) are to beunderstood to be inclusive of all similar equivalent objects (orclasses, or assets, or resources) corresponding to the same global nameon each one of the plurality of machines M1 . . . Mn. The waitingenquiring machine of step 182 is then able to respond and/or operateaccordingly, such as for example by (i) aborting (or pausing, orpostponing) execution of the initialization routine when the reply frommachine X of step 182 indicated that a similar equivalent local objecton another machine (such as a one of the plurality of machines M1 . . .Mn) corresponding to the global name of the object proposed to beinitialized of step 172 is already initialized elsewhere (i.e. isinitialized on a machine other than the machine proposing to carry outthe initialization); or (ii) by continuing (or resuming, or starting, orcommencing) execution of the initialization routine when the reply frommachine X of step 182 indicated that a similar equivalent local objecton the plurality of machines M1 . . . Mn corresponding to the globalname of the object proposing to be initialized of step 172 is notinitialized elsewhere (i.e. not initialized on a machine other than themachine proposing to carry out the initialization).

Reference is made to the accompanying Annexures in which: AnnexuresA1-A10 illustrate actual code in relation to fields, Annexure B1 is atypical code fragment from an unmodified <clinit> instruction, AnnexureB2 is an equivalent in respect of a modified <clinit> instruction,Annexure B3 is a typical code fragment from an unmodified <init>instruction, Annexure B4 is an equivalent in respect of a modified<init> instruction, In addition, Annexure B5 is an alternative to thecode of Annexure B2, and Annexure B6 is an alternative to the code ofAnnexure B4.

Furthermore, Annexure B7 is the source-code of InitClient which carriesout one embodiment of the steps of FIGS. 17 and 18, which queries an“initialization server” (for example a machine X) for the initializationstatus of the specified class or object with respect to the plurality ofsimilar equivalent classes or objects on the plurality of machines M1 .. . Mn. Annexure B8 is the source-code of InitServer which carries outone embodiment of the steps of FIG. 19, which receives an initializationstatus query sent by InitClient and in response returns thecorresponding initialization status of the specified class or object.Similarly, Annexure B9 is the source-code of the example applicationused in the before/after examples of Annexure B1-B6 (Repeated as TablesX through XV). And, Annexure B10 is the source-code of InitLoader whichcarries out one embodiment of the steps of FIGS. 16, 20, and 21, whichmodifies the example application program code of Annexure B9 inaccordance with one mode of this invention.

Annexures B1 and B2 (also reproduced in part in Tables X and XI below)are exemplary code listings that set forth the conventional orunmodified computer program software code (such as may be used in asingle machine or computer environment) of an initialization routine ofapplication program 50 and a post-modification excerpt of the sameinitialization routine such as may be used in embodiments of the presentinvention having multiple machines. The modified code that is added tothe initialization routine is highlighted in bold text.

It is noted that the disassembled compiled code in the annexure andportion repeated in the table is taken from the source-code of the file“example.java” which is included in the Annexure B4 (Table XIII). In theprocedure of Annexure B1 and Table X, the procedure name “Method<clinit>” of Step 001 is the name of the displayed disassembled outputof the clinit method of the compiled application code “example.java”.The method name “<clinit>” is the name of a class' initialization methodin accordance with the JAVA platform specification, and selected forthis example to indicate a typical mode of operation of a JAVAinitialization method. Overall the method is responsible forinitializing the class ‘example’ so that it may be used, and the stepsthe “example.java” code performs are described in turn.

First (Step 002) the JAVA virtual machine instruction “new #2<Classexample>” causes the JAVA virtual machine to instantiate a new classinstance of the example class indicated by the CONSTANT_Classref_infoconstant_pool item stored in the 2^(nd) index of the classfile structureof the application program containing this example <clinit> method andresults in a reference to an newly created object of type ‘example’being placed (pushed) on the stack of the current method frame of thecurrently executing thread.

Next (Step 003), the Java Virtual Machine instruction “dup” causes theJava Virtual Machine to duplicate the topmost item of the stack and pushthe duplicated item onto the topmost position of the stack of thecurrent method frame and results in the reference to the new created‘example’ object at the top of the stack being duplicated and pushedonto the stack.

Next (Step 004), the JAVA virtual machine instruction “invokespecial #3<Method example( )>” causes the JAVA virtual machine to pop the topmostitem off the stack of the current method frame and invoke the instanceinitialization method “<init>” on the popped object and results in the“<init>” constructor of the newly created ‘example’ object beinginvoked.

The Java Virtual Machine instruction “putstatic #3<Field examplecurrentExample>” (Step 005) causes the Java Virtual Machine to pop thetopmost value off the stack of the current method frame and store thevalue in the static field indicated by the CONSTANT_Fieldref_infoconstant-pool item stored in the 3^(rd) index of the classfile structureof the application program containing this example <clinit> method andresults in the reference to the newly created and initialized ‘example’object on the top of the stack of the current method frame being storedin the static reference field named “currentExample” of class ‘example’.

Finally, the Java Virtual Machine instruction “return” (Step 006) causesthe Java Virtual Machine to cease executing this <clinit> method byreturning control to the previous method frame and results intermination of execution of this <clinit> method.

As a result of these steps operating on a single machine of theconventional configurations in FIG. 1 and FIG. 2, the JAVA virtualmachine can keep track of the initialization status of a class in aconsistent, coherent and coordinated manner, and in executing the<clinit> method containing the initialization operations is able toensure that unwanted behaviour (for example execution of the <init>method of class ‘example.java’ more than once) such as may be caused byinconsistent and/or incoherent initialization operation, does not occur.Were these steps to be carried out on the plurality of machines of theconfigurations of FIG. 5 and FIG. 8 with the memory update andpropagation replication means of FIGS. 9, 10, 11, 12, and 13, andconcurrently executing the application program code 50 on each one ofthe plurality of machines M1 . . . Mn, the initialization operations ofeach concurrently executing application program occurrence on each oneof the machines would be performed without coordination between anyother of the occurrences on any other of the machine(s). Given thedesirable result of consistent, coordinated and coherent initializationoperation across a plurality of a machines, this prior art arrangementwould fail to perform such consistent coordinated initializationoperation across the plurality of machines, as each machine performsinitialization only locally and without any attempt to coordinate theirlocal initialization operation with any other similar initializationoperation on any one or more other machines. Such an arrangement wouldtherefore be susceptible to unwanted or other anomalous behaviour due touncoordinated, inconsistent and/or incoherent initialization states, andassociated initialization operation. Therefore it is desirable toovercome this limitation of the prior art arrangement.

In the exemplary code in Table XIV (Annexure B5), the code has beenmodified so that it solves the problem of consistent, coordinatedinitialization operation for a plurality of machines M1 . . . Mn, thatwas not solved in the code example from Table X (Annexure B1). In thismodified <clinit> method code, an “ldc #2<String “example”>” instructionis inserted before the “new #5” instruction in order to be the firstinstruction of the <clinit> method. This causes the JAVA virtual machineto load the item in the constant_pool at index 2 of the currentclassfile and store this item on the top of the stack of the currentmethod frame, and results in the reference to a String object of value“example” being pushed onto the stack.

Furthermore, the JAVA virtual machine instruction “invokestatic#3<Method Boolean isAlreadyLoaded(java.lang.String)>” is inserted afterthe “0 ldc #2” instruction so that the JAVA virtual machine pops thetopmost item off the stack of the current method frame (which inaccordance with the preceding “ldc #2” instruction is a reference to theString object with the value “example” which corresponds to the name ofthe class to which this <clinit> method belongs) and invokes the“isAlreadyLoaded” method, passing the popped item to the new methodframe as its first argument, and returning a boolean value onto thestack upon return from this “invokestatic” instruction. This change issignificant because it modifies the <clinit> method to execute the“isAlreadyLoaded” method and associated operations, corresponding to thestart of execution of the <clinit> method, and returns a booleanargument (indicating whether the class corresponding to this <clinit>method is initialized on another machine amongst the plurality ofmachines M1 . . . Mn) onto the stack of the executing method frame ofthe <clinit> method.

Next, two JAVA virtual machine instructions “ifeq 9” and “return” areinserted into the code stream after the “2 invokestatic #3” instructionand before the “new #5” instruction. The first of these twoinstructions, the “ifeq 9” instruction, causes the JAVA virtual machineto pop the topmost item off the stack and performs a comparison betweenthe popped value and zero. If the performed comparison succeeds (i.e. ifand only if the popped value is equal to zero), then execution continuesat the “9 new #5” instruction. If however the performed comparison fails(i.e. if and only if the popped value is not equal to zero), thenexecution continues at the next instruction in the code stream, which isthe “8 return” instruction. This change is particularly significantbecause it modifies the <clinit> method to either continue execution ofthe <clinit> method (i.e. instructions 9-19) if the returned value ofthe “isAlreadyLoaded” method was negative (i.e. “false”), or discontinueexecution of the <clinit> method (i.e. the “8 return” instructioncausing a return of control to the invoker of this <clinit> method) ifthe returned value of the “isAlreadyLoaded” method was positive (i.e.“true”).

The method void isAlreadyLoaded(java.lang.String), part of theInitClient code of Annexure B7, and part of the distributed runtimesystem (DRT) 71, performs the communications operations between machinesM1 . . . Mn to coordinate the execution of the <clinit> method amongstthe machines M1 . . . Mn. The is AlreadyLoaded method of this examplecommunicates with the InitServer code of Annexure B8 executing on amachine X of FIG. 15, by means of sending an “initialization statusrequest” to machine X corresponding to the class being “initialized”(i.e. the class to which this <clinit> method belongs). With referenceto FIG. 19 and Annexure B8, machine X receives the “initializationstatus request” corresponding to the class to which the <clinit> methodbelongs, and consults a table of initialization states or records todetermine the initialization state for the class to which the requestcorresponds.

If the class corresponding to the initialization status request is notinitialized on another machine other than the requesting machine, thenmachine X will send a response indicating that the class was not alreadyinitialized, and update a record entry corresponding to the specifiedclass to indicate the class is now initialized. Alternatively, if theclass corresponding to the initialization status request is initializedon another machine other than the requesting machine, then machine Xwill send a response indicating that the class is already initialized.Corresponding to the determination that the class to which thisinitialization status request pertains is not initialized on anothermachine other than the requesting machine, a reply is generated and sentto the requesting machine indicating that the class is not initialized.Additionally, machine X preferably updates the entry corresponding tothe class to which the initialization status request pertained toindicate the class is now initialized. Following a receipt of such amessage from machine X indicating that the class is not initialized onanother machine, the is AlreadyLoaded( ) method and operations terminateexecution and return a ‘false’ value to the previous method frame, whichis the executing method frame of the <clinit> method. Alternatively,following a receipt of a message from machine X indicating that theclass is already initialized on another machine, the is AlreadyLoaded( )method and operations terminate execution and return a “true” value tothe previous method frame, which is the executing method frame of the<clinit> method. Following this return operation, the execution of the<clinit> method frame then resumes as indicated in the code sequence ofAnnexure B5 at step 004.

It will be appreciated that the modified code permits, in a distributedcomputing environment having a plurality of computers or computingmachines, the coordinated operation of initialization routines or otherinitialization operations between and amongst machines M1 . . . Mn sothat the problems associated with the operation of the unmodified codeor procedure on a plurality of machines M1 . . . Mn (such as for examplemultiple initialization operation, or re-initialization operation) doesnot occur when applying the modified code or procedure.

Similarly, the procedure followed to modify an <init> method relating toobjects so as to convert from the code fragment of Annexure B3 (SeeTable XII) to the code fragment of Annexure B6 (See Table XV) isindicated.

Annexures B3 and B6 (also reproduced in part in Tables XII and XV below)are exemplary code listings that set forth the conventional orunmodified computer program software code (such as may be used in asingle machine or computer environment) of an initialization routine ofapplication program 50 and a post-modification excerpt of the sameinitialization routine such as may be used in embodiments of the presentinvention having multiple machines. The modified code that is added tothe initialization routine is highlighted in bold text.

It is noted that the disassembled compiled code in the annexure andportion repeated in the table is taken from the source-code of the file“example.java” which is included in the Annexure B4. In the procedure ofAnnexure B1 and Table XI, the procedure name “Method <init>” of Step 001is the name of the displayed disassembled output of the init method ofthe compiled application code “example.java”. The method name “<init>”is the name of an object's initialization method (or methods, as theremay be more than one) in accordance with the JAVA platformspecification, and selected for this example to indicate a typical modeof operation of a JAVA initialization method. Overall the method isresponsible for initializing an ‘example’ object so that it may be used,and the steps the “example.java” code performs are described in turn.

The Java Virtual Machine instruction “aload_(—)0” (Step 002) causes theJava Virtual Machine to load the item in the local variable array atindex 0 of the current method frame and store this item on the top ofthe stack of the current method frame and results in the ‘this’ objectreference stored in the local variable array at index 0 being pushedonto the stack.

Next (Step 003), the JAVA virtual machine instruction “invokespecial #1<Method java.lang.Object( )>” causes the JAVA virtual machine to pop thetopmost item off the stack of the current method frame and invoke theinstance initialization method “<init>” on the popped object and resultsin the “<init>” constructor (or method) of the ‘example’ object'ssuperclass being invoked.

The Java Virtual Machine instruction “aload_(—)0” (Step 004) causes theJava Virtual Machine to load the item in the local variable array atindex 0 of the current method frame and store this item on the top ofthe stack of the current method frame and results in the ‘this’ objectreference stored in the local variable array at index 0 being pushedonto the stack.

Next (Step 005), the JAVA virtual machine instruction “invokestatic#2<Method long currentTimeMillis( )>” causes the JAVA virtual machine toinvoke the “currentTimeMillis( )” method of the java.lang.System class,and results in a long value pushed onto the top of the stackcorresponding to the return value from the currentTimeMillis( ) methodinvocation.

The Java Virtual Machine instruction “putfield #3<Field long timestamp>”(Step 006) causes the Java Virtual Machine to pop the two topmost valuesoff the stack of the current method frame and store the topmost value inthe object instance field of the second popped value, indicated by theCONSTANT_Fieldref_info constant-pool item stored in the 3^(rd) index ofthe classfile structure of the application program containing thisexample <init> method, and results in the long value on the top of thestack of the current method frame being stored in the instance fieldnamed “timestamp” of the object reference below the long value on thestack.

Finally, the Java Virtual Machine instruction “return” (Step 007) causesthe Java Virtual Machine to cease executing this <init> method byreturning control to the previous method frame and results intermination of execution of this <init> method.

As a result of these steps operating on a single machine of theconventional configurations in FIG. 1 and FIG. 2, the JAVA virtualmachine can keep track of the initialization status of an object in aconsistent, coherent and coordinated manner, and in executing the <init>method containing the initialization operations is able to ensure thatunwanted behaviour (for example execution of the <init> method of asingle ‘example.java’ object more than once, or re-initialization of thesame object) such as may be caused by inconsistent and/or incoherentinitialization operation, does not occur. Were these steps to be carriedout on the plurality of machines of the configurations of FIG. 5 andFIG. 8 with the memory update and propagation replication means of FIGS.9, 10, 11, 12, and 13, and concurrently executing the applicationprogram code 50 on each one of the plurality of machines M1 . . . Mn,the initialization operations of each concurrently executing applicationprogram occurrence on each one of the machines would be performedwithout coordination between any other of the occurrences on any otherof the machine(s). Given the desirable result of consistent, coordinatedand coherent initialization operation across a plurality of a machines,this prior art arrangement would fail to perform such consistentcoordinated initialization operation across the plurality of machines,as each machine performs initialization only locally and without anyattempt to coordinate their local initialization operation with anyother similar initialization operation on any one or more othermachines. Such an arrangement would therefore be susceptible to unwantedor other anomalous behaviour due to uncoordinated, inconsistent and/orincoherent initialization states, and associated initializationoperation. Therefore it is desirable to overcome this limitation of theprior art arrangement.

In the exemplary code in Table XV (Annexure B6), the code has beenmodified so that it solves the problem of consistent, coordinatedinitialization operation for a plurality of machines M1 . . . Mn, thatwas not solved in the code example from Table XII (Annexure B3). In thismodified <init> method code, an “aload_(—)0” instruction is insertedafter the “1 invokespecial #1” instruction, as the “invokespecial #1”instruction must execute before the object may be further used. Thisinserted “aload_(—)0” instruction causes the JAVA virtual machine toload the item in the local variable array at index 0 of the currentmethod frame and store this item on the top of the stack of the currentmethod frame, and results in the object reference to the ‘this’ objectat index 0 being pushed onto the stack.

Furthermore, the JAVA virtual machine instruction “invokestatic#3<Method Boolean is AlreadyLoaded(java.lang.Object)>” is inserted afterthe “4 aload_(—)0” instruction so that the JAVA virtual machine pops thetopmost item off the stack of the current method frame (which inaccordance with the preceding “aload_(—)0” instruction is a reference tothe object to which this <init> method belongs) and invokes the “isAlreadyLoaded” method, passing the popped item to the new method frameas its first argument, and returning a boolean value onto the stack uponreturn from this “invokestatic” instruction. This change is significantbecause it modifies the <init> method to execute the “is AlreadyLoaded”method and associated operations, corresponding to the start ofexecution of the <init> method, and returns a boolean argument(indicating whether the object corresponding to this <init> method isinitialized on another machine amongst the plurality of machines M1 . .. Mn) onto the stack of the executing method frame of the <init> method.

Next, two JAVA virtual machine instructions “ifeq 13” and “return” areinserted into the code stream after the “5 invokestatic #2” instructionand before the “12 aload_(—)0” instruction. The first of these twoinstructions, the “ifeq 13” instruction, causes the JAVA virtual machineto pop the topmost item off the stack and performs a comparison betweenthe popped value and zero. If the performed comparison succeeds (i.e. ifand only if the popped value is equal to zero), then execution continuesat the “12 aload_(—)0” instruction. If however the performed comparisonfails (i.e. if and only if the popped value is not equal to zero), thenexecution continues at the next instruction in the code stream, which isthe “11 return” instruction. This change is particularly significantbecause it modifies the <init> method to either continue execution ofthe <init> method (i.e. instructions 12-19) if the returned value of the“is AlreadyLoaded” method was negative (i.e. “false”), or discontinueexecution of the <init> method (i.e. the “11 return” instruction causinga return of control to the invoker of this <init> method) if thereturned value of the “is AlreadyLoaded” method was positive (i.e.“true”).

The method void is AlreadyLoaded(java.lang.Object), part of theInitClient code of Annexure B7, and part of the distributed runtimesystem (DRT) 71, performs the communications operations between machinesM1 . . . Mn to coordinate the execution of the <init> method amongst themachines M1 . . . Mn. The is AlreadyLoaded method of this examplecommunicates with the InitServer code of Annexure B8 executing on amachine X of FIG. 15, by means of sending an “initialization statusrequest” to machine X corresponding to the object being “initialized”(i.e. the object to which this <clinit> method belongs). With referenceto FIG. 19 and Annexure B8, machine X receives the “initializationstatus request” corresponding to the object to which the <clinit> methodbelongs, and consults a table of initialization states or records todetermine the initialization state for the object to which the requestcorresponds.

If the object corresponding to the initialization status request is notinitialized on another machine other than the requesting machine, thenmachine X will send a response indicating that the object was notalready initialized, and update a record entry corresponding to thespecified object to indicate the object is now initialized.Alternatively, if the object corresponding to the initialization statusrequest is initialized on another machine other than the requestingmachine, then machine X will send a response indicating that the objectis already initialized. Corresponding to the determination that theobject to which this initialization status request pertains is notinitialized on another machine other than the requesting machine, areply is generated and sent to the requesting machine indicating thatthe object is not initialized. Additionally, machine X preferablyupdates the entry corresponding to the object to which theinitialization status request pertained to indicate the object is nowinitialized. Following a receipt of such a message from machine Xindicating that the object is not initialized on another machine, the isAlreadyLoaded( ) method and operations terminate execution and return a‘false’ value to the previous method frame, which is the executingmethod frame of the <init> method. Alternatively, following a receipt ofa message from machine X indicating that the object is alreadyinitialized on another machine, the is AlreadyLoaded( ) method andoperations terminate execution and return a “true” value to the previousmethod frame, which is the executing method frame of the <init> method.Following this return operation, the execution of the <init> methodframe then resumes as indicated in the code sequence of Annexure B5 atstep 006.

It will be appreciated that the modified code permits, in a distributedcomputing environment having a plurality of computers or computingmachines, the coordinated operation of initialization routines or otherinitialization operations so that the problems associated with theoperation of the unmodified code or procedure on a plurality of machinesM1 . . . Mn (such as for example multiple initialization, orre-initialization operation) does not occur when applying the modifiedcode or procedure.

Annexure B1 is a before-modification excerpt of the disassembledcompiled form of the <clinit> method of the example.java application ofAnnexure B9. Annexure B2 is an after-modification form of Annexure B1,modified by InitLoader.java of Annexure B10 in accordance with the stepsof FIG. 20. Annexure B3 is a before-modification excerpt of thedisassembled compiled form of the <init> method of the example.javaapplication of Annexure B9. Annexure B4 is an after-modification form ofAnnexure B3, modified by InitLoader.java of Annexure B10 in accordancewith the steps of FIG. 21. Annexure B5 is an alternativeafter-modification form of Annexure B1, modified by InitLoader.java ofAnnexure B10 in accordance with the steps of FIG. 20. And Annexure B6 isan alternative after-modification form of Annexure B3, modified byInitLoader.java of Annexure B10 in accordance with the steps of FIG. 21.The modifications are highlighted in bold.

TABLE X Annexure B1 B1 Method <clinit>  0 new #2 <Class example>  3 dup 4 invokespecial #3 <Method example( )>  7 putstatic #4 <Field examplecurrentExample>   10 return

TABLE XI Annexure B2 B2 Method <clinit>  0 invokestatic #3 <Methodboolean isAlreadyLoaded( )>  3 ifeq 7  6 return  7 new #5 <Classexample>   10 dup   11 invokespecial #6 <Method example( )>   14putstatic #7 <Field example example>   17 return

TABLE XII Annexure B3 B3 Method <init>  0 aload_0  1 invokespecial #1<Method java.lang.Object( )>  4 aload_0  5 invokestatic #2 <Method longcurrentTimeMillis( )>  8 putfield #3 <Field long timestamp>   11 return

TABLE XIII Annexure B4 B4 Method <init>  0 aload_0  1 invokespecial #1<Method java.lang.Object( )>  4 invokestatic #2 <Method booleanisAlreadyLoaded( )>  7 ifeq 11   10 return   11 aload_0   12invokestatic #4 <Method long currentTimeMillis( )>   15 putfield #5<Field long timestamp>   18 return

TABLE XIV Annexure B5 B5 Method <clinit>  0 ldc #2 <String “example”>  2invokestatic #3 <Method boolean isAlreadyLoaded(java.lang.String)>  5ifeq 9  8 return  9 new #5 <Class example>   12 dup   13 invokespecial#6 <Method example( )>   16 putstatic #7 <Field example currentExample>  19 return

TABLE XV Annexure B6 B6 Method <init>  0 aload_0  1 invokespecial #1<Method java.lang.Object( )>  4 aload_0  5 invokestatic #2 <Methodboolean isAlreadyLoaded(java.lang.Object)>  8 ifeq 12   11 return   12aload_0   13 invokestatic #4 <Method long currentTimeMillis( )>   16putfield #5 <Field long timestamp>   19 return

Turning now to FIGS. 20 and 21, the procedure followed to modify classinitialisation routines (i.e., the “<clinit>” method) and objectinitialization routines (i.e. the “<init>” method) is presented. Theprocedure followed to modify a <clinit> method relating to classes so asto convert from the code fragment of Annexure B1 (See Table X) to thecode fragment of Annexure B5 (See Table XIV) is indicated.

Similarly, the procedure followed to modify an object initialization<init> method relating to objects so as to convert from the codefragment of Annexure B3 (See Table XII) to the code fragment of AnnexureB6 (See Table XV) is indicated.

The initial loading of the application code 50 (an illustrative examplein source-code form of which is displayed in Annexure B9, and acorresponding partially disassembled form of which is displayed inAnnexure B1 (See also Table X) and Annexure B3 (See also Table XII))onto the JAVA virtual machine 72 is commenced at step 201, and the codeis analysed or scrutinized in order to detect one or more classinitialization instructions, code-blocks or methods (i.e. “<clinit>”methods) by carrying out step 202, and/or one or more objectinitialization instructions, code-blocks, or methods (i.e. “<init>”methods) by carrying out step 212. Once so detected, an <clinit> methodis modified by carrying out step 203, and an <init> method is modifiedby carrying out step 213. One example illustration for a modified classinitialisation routine is indicated in Annexure B2 (See also Table XI),and a further illustration of which is indicated in Annexure B5 (Seealso Table XIV). One example illustration for a modified objectinitialisation routine is indicated in Annexure B4 (See also TableXIII), and a further illustration of which is indicated in Annexure B6(See also Table XV). As indicated by step 204 and 214, after themodification is completed the loading procedure is then continued suchthat the modified application code is loaded into or onto each of themachines instead of the unmodified application code.

Annexure B1 (See also Table X) and Annexure B2 (See also Table XI) arethe before (or pre-modification or unmodified code) and after (orpost-modification or modified code) excerpt of a class initialisationroutine (i.e. a “<clinit>” method) respectively. Additionally, a furtherexample of an alternative modified <clinit> method is illustrated inAnnexure B5 (See also Table XIV). The modified code that is added to themethod is highlighted in bold. In the unmodified partially disassembledcode sample of Annexure B1, the “new #2” and “invokespecial #3”instructions of the <clinit> method creates a new object (of the type‘example’), and the following instruction “putstatic #4” writes thereference of this newly created object to the memory location (field)called “currentExample”. Thus, without management of coordinated classinitialisation in a distributed environment of a plurality of machinesM1, . . . , Mn, and each with a memory updating and propagation means ofFIGS. 9, 10, 11, 12, and 13, whereby the application program code 50 isto operate as a single coordinated, consistent, and coherent instanceacross the plurality of machines M1 . . . Mn, each computer or computingmachine would re-initialise (and optionally alternatively re-write orover-write) the “currentExample” memory location (field) with multipleand different objects corresponding to the multiple executions of the<clinit> method, leading to potentially incoherent or inconsistentmemory between and amongst the occurrences of the application programcode 50 on each of the machines M1, . . . , Mn. Clearly this is not whatthe programmer or user of a single application program code 50 instanceexpects to happen.

So, taking advantage of the DRT, the application code 50 is modified asit is loaded into the machine by changing the class initialisationroutine (i.e., the <clinit> method). The changes made (highlighted inbold) are the initial instructions that the modified <clinit> methodexecutes. These added instructions determine the initialization statusof this particular class by checking if a similar equivalent local classon another machine corresponding to this particular class, has alreadybeen initialized and optionally loaded, by calling a routine orprocedure to determine the initialization status of the plurality ofsimilar equivalent classes, such as the “is already loaded” (e.g., “isAlreadyLoaded( )”) procedure or method. The “is AlreadyLoaded( )” methodof InitClient of Annexure B7 of DRT 71 performing the steps of 172-176of FIG. 17 determines the initialization status of the similarequivalent local classes each on a one of the machines M1, . . . , Mncorresponding to the particular class being loaded, the result of whichis either a true result or a false result corresponding to whether ornot another one (or more) of the machines M1 . . . Mn have alreadyinitialized, and optionally loaded, a similar equivalent class.

The initialisation determination procedure or method “is AlreadyLoaded()” of InitClient of Annexure B7 of the DRT 71 can optionally take anargument which represents a unique identifier for this class (SeeAnnexure B5 and Table XIV). For example, the name of the class that isbeing considered for initialisation, a reference to the class orclass-object representing this class being considered forinitialization, or a unique number or identifier representing this classacross all machines (that is, a unique identifier corresponding to theplurality of similar equivalent local classes each on a one of theplurality of machines M1 . . . Mn), to be used in the determination ofthe initialisation status of the plurality of similar equivalent localclasses on each of the machines M1 . . . Mn. This way, the DRT cansupport the initialization of multiple classes at the same time withoutbecoming confused as to which of the multiple classes are already loadedand which are not, by using the unique identifier of each class.

The DRT 71 can determine the initialization status of the class in anumber of possible ways. Preferably, the requesting machine can ask eachother requested machine in turn (such as by using a computercommunications network to exchange query and response messages betweenthe requesting machine and the requested machine(s)) if the requestedmachine's similar equivalent local class corresponding to the uniqueidentifier is initialized, and if any requested machine replies trueindicating that the similar equivalent local class has already beeninitialized, then return a true result at return from the isAlreadyLoaded( ) method indicating that the local class should not beinitialized, otherwise return a false result at return from the isAlreadyLoaded( ) method indicating that the local class should beinitialized. Of course different logic schemes for true or false resultsmay alternatively be implemented with the same effect. Alternatively,the DRT on the local machine can consult a shared record table (perhapson a separate machine (eg machine X), or a coherent shared record tableon each local machine and updated to remain substantially identical, orin a database) to determine if one of the plurality of similarequivalent classes on other machines has been initialised.

If the is AlreadyLoaded( ) method of the DRT 71 returns false, then thismeans that this class (of the plurality of similar equivalent localclasses on the plurality of machines M1 . . . Mn) has not beeninitialized before on any other machine in the distributed computingenvironment of the plurality of machines M1 . . . Mn, and hence, theexecution of the class initialisation method is to take place or proceedas this is considered the first and original initialization of a classof the plurality of similar equivalent classes on each machine. As aresult, when a shared record table of initialisation states exists, theDRT must update the initialisation status record corresponding to thisclass in the shared record table to true or other value indicating thatthis class is initialized, such that subsequent consultations of theshared record table of initialisation states (such as performed by allsubsequent invocations of is AlreadyLoaded method) by all machines, andoptionally including the current machine, will now return a true valueindicating that this class is already initialized. Thus, if isAlreadyLoaded( ) returns false, the modified class initialisationroutine resumes or continues (or otherwise optionally begins or starts)execution.

On the other hand, if the is AlreadyLoaded method of the DRT 71 returnstrue, then this means that this class (of the plurality of similarequivalent local classes each on one of the plurality of machines M1 . .. Mn) has already been initialised in the distributed environment, asrecorded in the shared record table on machine X of the initialisationstates of classes. In such a case, the class initialisation method isnot to be executed (or alternatively resumed, or continued, or started,or executed to completion), as it will potentially cause unwantedinteractions or conflicts, such as re-initialization of memory, datastructures or other machine resources or devices. Thus, when the DRTreturns true, the inserted instructions at the start of the <clinit>method prevent execution of the initialization routine (optionally inwhole or in part) by aborting the start or continued execution of the<clinit> method through the use of the return instruction, andconsequently aborting the JAVA Virtual Machine's initializationoperation for this class.

An equivalent procedure for the initialization routines of object (forexample “<init>” methods) is illustrated in FIG. 21 where steps 212 and213 are equivalent to steps 202 and 203 of FIG. 20. This results in thecode of Annexure B3 being converted into the code of Annexure B4 (Seealso Table XIII) or Annexure B6 (See also Table XV).

Annexure B3 (See also Table XII) and Annexure B4 (See also Table XIV)are the before (or pre-modification or unmodified code) and after (orpost-modification or modified code) excerpt of a object initialisationroutine (i.e. a “<init>” method) respectively. Additionally, a furtherexample of an alternative modified <init> method is illustrated inAnnexure B6 (See also Table XV). The modified code that is added to themethod is highlighted in bold. In the unmodified partially disassembledcode sample of Annexure B4, the “aload_(—)0” and “invokespecial #3”instructions of the <init> method invokes the <init> of thejava.lang.Object superclass. Next, the following instructions“aload_(—)0” loads a reference to the ‘this’ object onto the stack to beone of the arguments to the “8 putfield #3” instruction. Next, thefollowing instruction “invokestatic #2” invokes the methodjava.lang.System.currentTimeMillis( ) and returns a long value on thestack. Next the following instruction “putfield #3” writes the longvalue placed on the stack be the preceding “invokestatic #2” instructionto the memory location (field) called “timestamp” corresponding to theobject instance loaded on the stack by the “4 aload_(—)0” instruction.Thus, without management of coordinated object initialisation in adistributed environment of a plurality of machines M1, . . . , Mn, andeach with a memory updating and propagation means of FIGS. 9, 10, 11,12, and 13, whereby the application program code 50 is to operate as asingle co-ordinated, consistent, and coherent instance across theplurality of machines M1 . . . Mn, each computer or computing machinewould re-initialise (and optionally alternatively re-write orover-write) the “timestamp” memory location (field) with multiple anddifferent values corresponding to the multiple executions of the <init>method, leading to potentially incoherent or inconsistent memory betweenand amongst the occurrences of application program code 50 on each ofthe machines M1, . . . , Mn. Clearly this is not what the programmer oruser of a single application program code 50 instance expects to happen.

So, taking advantage of the DRT, the application code 50 is modified asit is loaded into the machine by changing the object initialisationroutine (i.e. the <init> method). The changes made (highlighted in bold)are the initial instructions that the modified <init> method executes.These added instructions determine the initialisation status of thisparticular object by checking if a similar equivalent local object onanother machine corresponding to this particular object, has alreadybeen initialized and optionally loaded, by calling a routine orprocedure to determine the initialisation status of the object to beinitialised, such as the “is already loaded” (e.g., “is AlreadyLoaded()”) procedure or method of Annexure B7. The “is AlreadyLoaded( )” methodof DRT 71 performing the steps of 172-176 of FIG. 17 determines theinitialization status of the similar equivalent local objects each on aone of the machines M1, . . . , Mn corresponding to the particularobject being loaded, the result of which is either a true result or afalse result corresponding to whether or not another one (or more) ofthe machines M1 . . . Mn have already initialized, and optionallyloaded, this object.

The initialisation determination procedure or method “is AlreadyLoaded()” of the DRT 71 can optionally take an argument which represents aunique identifier for this object (See Annexure B6 and Table XV). Forexample, the name of the object that is being considered forinitialisation, a reference to the object being considered forinitialization, or a unique number or identifier representing thisobject across all machines (that is, a unique identifier correspondingto the plurality of similar equivalent local objects each on a one ofthe plurality of machines M1 . . . Mn), to be used in the determinationof the initialisation status of this object in the plurality of similarequivalent local objects on each of the machines M1 . . . Mn. This way,the DRT can support the initialization of multiple objects at the sametime without becoming confused as to which of the multiple objects arealready loaded and which are not, by using the unique identifier of eachobject.

The DRT 71 can determine the initialization status of the object in anumber of possible ways. Preferably, the requesting machine can ask eachother requested machine in turn (such as by using a computercommunications network to exchange query and response messages betweenthe requesting machine and the requested machine(s)) if the requestedmachine's similar equivalent local object corresponding to the uniqueidentifier is initialized, and if any requested machine replies trueindicating that the similar equivalent local object has already beeninitialized, then return a true result at return from the isAlreadyLoaded( ) method indicating that the local object should not beinitialized, otherwise return a false result at return from the isAlreadyLoaded( ) method indicating that the local object should beinitialized. Of course different logic schemes for true or false resultsmay alternatively be implemented with the same effect. Alternatively,the DRT on the local machine can consult a shared record table (perhapson a separate machine (eg machine X), or a coherent shared record tableon each local machine and updated to remain substantially identical, orin a database) to determine if this particular object (or any one of theplurality of similar equivalent objects on other machines) has beeninitialised by one of the requested machines.

If the is AlreadyLoaded( ) method of the DRT 71 returns false, then thismeans that this object (of the plurality of similar equivalent localobjects on the plurality of machines M1 . . . Mn) has not beeninitialized before on any other machine in the distributed computingenvironment of the plurality of machines M1 . . . Mn, and hence, theexecution of the object initialisation method is to take place orproceed as this is considered the first and original initialization. Asa result, when a shared record table of initialisation states exists,the DRT must update the initialisation status record corresponding tothis object in the shared record table to true or other value indicatingthat this object is initialized, such that subsequent consultations ofthe shared record table of initialisation states (such as performed byall subsequent invocations of is AlreadyLoaded method) by all machines,and including the current machine, will now return a true valueindicating that this object is already initialized. Thus, if isAlreadyLoaded( ) returns false, the modified object initialisationroutine resumes or continues (or otherwise optionally begins or starts)execution.

On the other hand, if the is AlreadyLoaded method of the DRT 71 returnstrue, then this means that this object (of the plurality of similarequivalent local objects each on one of the plurality of machines M1 . .. Mn) has already been initialised in the distributed environment, asrecorded in the shared record table on machine X of the initialisationstates of objects. In such a case, the object initialisation method isnot to be executed (or alternatively resumed, or continued, or started,or executed to completion), as it will potentially cause unwantedinteractions or conflicts, such as re-initialization of memory, datastructures or other machine resources or devices. Thus, when the DRTreturns true, the inserted instructions near the start of the <init>method prevent execution of the initialization routine (optionally inwhole or in part) by aborting the start or continued execution of the<init> method through the use of the return instruction, andconsequently aborting the JAVA Virtual Machine's initializationoperation for this object.

A similar modification as used for <clinit> is used for <init>. Theapplication program's <init> method (or methods, as there may bemultiple) is or are detected as shown by step 212 and modified as shownby step 213 to behave coherently across the distributed environment.

The disassembled instruction sequence after modification has taken placeis set out in Annexure B4 (and an alternative similar arrangement isprovided in Annexure B6) and the modified/inserted instructions arehighlighted in bold. For the <init> modification, unlike the <clinit>modification, the modifying instructions are often required to be placedafter the “invokespecial” instruction, instead of at the very beginning.The reasons for this are driven by the JAVA Virtual Machinespecification. Other languages often have similar subtle design nuances.

Given the fundamental concept of testing to determine if initializationhas already been carried out on a one of a plurality of similarequivalent classes or object or other asset each on a one of themachines M1 . . . Mn, and if not carrying out the initialization, and ifso, not carrying out the initialization; there are several differentways or embodiments in which this coordinated and coherentinitialization concept, method, and procedure may be carried out orimplemented.

In the first embodiment, a particular machine, say machine M2, loads theasset (such as class or object) inclusive of an initialisation routine,modifies it, and then loads each of the other machines M1, M3, . . . ,Mn (either sequentially or simultaneously or according to any otherorder, routine or procedure) with the modified object (or class or otherasset or resource) inclusive of the new modified initializationroutine(s). Note that there may be one or a plurality of routinescorresponding to only one object in the application code, or there maybe a plurality of routines corresponding to a plurality of objects inthe application code. Note that in one embodiment, the initializationroutine(s) that is (are) loaded is binary executable object code.Alternatively, the initialization routine(s) that is (are) loaded isexecutable intermediary code.

In this arrangement, which may be termed “master/slave” each of theslave (or secondary) machines M1, M3, . . . , Mn loads the modifiedobject (or class), and inclusive of the new modified initialisationroutine(s), that was sent to it over the computer communications networkor other communications link or path by the master (or primary) machine,such as machine M2, or some other machine such as a machine X of FIG.15. In a slight variation of this “master/slave” or “primary/secondary”arrangement, the computer communications network can be replaced by ashared storage device such as a shared file system, or a shareddocument/file repository such as a shared database.

Note that the modification performed on each machine or computer neednot and frequently will not be the same or identical. What is requiredis that they are modified in a similar enough way that in accordancewith the inventive principles described herein, each of the plurality ofmachines behaves consistently and coherently relative to the othermachines to accomplish the operations and objectives described herein.Furthermore, it will be appreciated in light of the description providedherein that there are a myriad of ways to implement the modificationsthat may for example depend on the particular hardware, architecture,operating system, application program code, or the like or differentfactors. It will also be appreciated that embodiments of the inventionmay be implemented within an operating system, outside of or without thebenefit of any operating system, inside the virtual machine, in anEPROM, in software, in firmware, or in any combination of these.

In a further variation of this “master/slave” or “primary/secondary”arrangement, machine M2 loads asset (such as class or object) inclusiveof an (or even one or more) initialization routine in unmodified form onmachine M2, and then (for example, machine M2 or each local machine)modifies the class (or object or asset) by deleting the initializationroutine in whole or part from the asset (or class or object) and loadsby means of a computer communications network or other communicationslink or path the modified code for the asset with the now modified ordeleted initialization routine on the other machines. Thus in thisinstance the modification is not a transformation, instrumentation,translation or compilation of the asset initialization routine but adeletion of the initialization routine on all machines except one.

The process of deleting the initialization routine in its entirety caneither be performed by the “master” machine (such as machine M2 or someother machine such as machine X of FIG. 15) or alternatively by eachother machine M1, M3, . . . , Mn upon receipt of the unmodified asset.An additional variation of this “master/slave” or “primary/secondary”arrangement is to use a shared storage device such as a shared filesystem, or a shared document/file repository such as a shared databaseas means of exchanging the code (including for example, the modifiedcode) for the asset, class or object between machines M1, M2, . . . , Mnand optionally a machine X of FIG. 15.

In a still further embodiment, each machine M1, . . . , Mn receives theunmodified asset (such as class or object) inclusive of one or moreinitialization routines, but modifies the routines and then loads theasset (such as class or object) consisting of the now modified routines.Although one machine, such as the master or primary machine maycustomize or perform a different modification to the initializationroutine sent to each machine, this embodiment more readily enables themodification carried out by each machine to be slightly different and tobe enhanced, customized, and/or optimized based upon its particularmachine architecture, hardware, processor, memory, configuration,operating system, or other factors, yet still similar, coherent andconsistent with other machines with all other similar modifications andcharacteristics that may not need to be similar or identical.

In a further arrangement, a particular machine, say M1, loads theunmodified asset (such as class or object) inclusive of one or moreinitialisation routine and all other machines M2, M3, . . . , Mn performa modification to delete the initialization routine of the asset (suchas class or object) and load the modified version.

In all of the described instances or embodiments, the supply or thecommunication of the asset code (such as class code or object code) tothe machines M1, . . . , Mn, and optionally inclusive of a machine X ofFIG. 15, can be branched, distributed or communicated among and betweenthe different machines in any combination or permutation; such as byproviding direct machine to machine communication (for example, M2supplies each of M1, M3, M4, etc. directly), or by providing or usingcascaded or sequential communication (for example, M2 supplies M1 whichthen supplies M3 which then supplies M4, and so on), or a combination ofthe direct and cascaded and/or sequential.

In a still further arrangement, the initial machine, say M2, can carryout the initial loading of the application code 50, modify it inaccordance with this invention, and then generate a class/object loadedand initialised table which lists all or at least all the pertinentclasses and/or objects loaded and initialised by machine M2. This tableis then sent or communicated (or at least its contents are sent orcommunicated) to all other machines (including for example in branchedor cascade fashion). Then if a machine, other than M2, needs to load andtherefore initialise a class listed in the table, it sends a request toM2 to provide the necessary information, optionally consisting of eitherthe unmodified application code 50 of the class or object to be loaded,or the modified application code of the class or object to be loaded,and optionally a copy of the previously initialised (or optionally andif available, the latest or even the current) values or contents of thepreviously loaded and initialised class or object on machine M2. Analternative arrangement of this mode may be to send the request fornecessary information not to machine M2, but some other, or even morethan one of, machine M1, . . . Mn or machine X. Thus the informationprovided to machine Mn is, in general, different from the initial stateloaded and initialise by machine M2.

Under the above circumstances it is preferable and advantageous for eachentry in the table to be accompanied by a counter which is incrementedon each occasion that a class or object is loaded and initialised on oneof the machines M1, . . . , Mn. Thus, when data or other content isdemanded, both the class or object contents and the count of thecorresponding counter, and optionally in addition the modified orunmodified application code, are transferred in response to the demand.This “on demand” mode may somewhat increase the overhead of theexecution of this invention for one or more machines M1, . . . Mn, butit also reduces the volume of traffic on the communications networkwhich interconnects the computers and therefore provides an overalladvantage.

In a still further arrangement, the machines M1 to Mn, may send some orall load requests to an additional machine X (see for example theembodiment of FIG. 15), which performs the modification to theapplication code 50 inclusive of an (and possibly a plurality of)initialisation routine(s) via any of the afore mentioned methods, andreturns the modified application code inclusive of the now modifiedinitialization routine(s) to each of the machines M1 to Mn, and thesemachines in turn load the modified application code inclusive of themodified routines locally. In this arrangement, machines M1 to Mnforward all load requests to machine X, which returns a modifiedapplication program code 50 inclusive of modified initializationroutine(s) to each machine. The modifications performed by machine X caninclude any of the modifications covered under the scope of the presentinvention. This arrangement may of course be applied to some of themachines and other arrangements described herein before applied to otherof the machines.

Persons skilled in the computing arts will be aware of various possibletechniques that may be used in the modification of computer code,including but not limited to instrumentation, program transformation,translation, or compilation means.

One such technique is to make the modification(s) to the applicationcode, without a preceding or consequential change of the language of theapplication code. Another such technique is to convert the original code(for example, JAVA language source-code) into an intermediaterepresentation (or intermediate-code language, or pseudo code), such asJAVA byte code. Once this conversion takes place the modification ismade to the byte code and then the conversion may be reversed. Thisgives the desired result of modified JAVA code.

A further possible technique is to convert the application program tomachine code, either directly from source-code or via the abovementionedintermediate language or through some other intermediate means. Then themachine code is modified before being loaded and executed. A stillfurther such technique is to convert the original code to anintermediate representation, which is thus modified and subsequentlyconverted into machine code.

The present invention encompasses all such modification routes and alsoa combination of two, three or even more, of such routes.

Finalization

Turning again to FIG. 14, there is illustrated a schematicrepresentation of a single prior art computer operated as a JAVA virtualmachine. In this way, a machine (produced by any one of variousmanufacturers and having an operating system operating in any one ofvarious different languages) can operate in the particular language ofthe application program code 50, in this instance the JAVA language.That is, a JAVA virtual machine 72 is able to operate application code50 in the JAVA language, and utilize the JAVA architecture irrespectiveof the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment,the generalized platform, and/or virtual machine and/or machine and/orruntime system is able to operate application code 50 in the language(s)(possibly including for example, but not limited to any one or more ofsource-code languages, intermediate-code languages, object-codelanguages, machine-code languages, and any other code languages) of thatplatform, and/or virtual machine and/or machine and/or runtime systemenvironment, and utilize the platform, and/or virtual machine and/ormachine and/or runtime system and/or language architecture irrespectiveof the machine manufacturer and the internal details of the machine. Itwill also be appreciated in light of the description provided hereinthat the platform and/or runtime system may include virtual machine andnon-virtual machine software and/or firmware architectures, as well ashardware and direct hardware coded applications and implementations.

Furthermore, when there is only a single computer or machine 72, thesingle machine of FIG. 14 is able to easily keep track of whether thespecific objects 50X, 50Y, and/or 50Z are, liable to be required by theapplication code 50 at a later point of execution of the applicationcode 50. This may typically be done by maintaining a “handle count” orsimilar count or index for each object and/or class. This count maytypically keep track of the number of places or times in the executingapplication code 50 where reference is made to a specific object (orclass). For a handle count (or other count or index based)implementation that increments the handle count (or index) upward when anew reference to the object or class is created or assigned, anddecrements the handle count (or index) downward when a reference to theobject or class is destroyed or lost, when the object handle count for aspecific object reaches zero, there is nowhere in the executingapplication code 50 which makes reference to the specific object (orclass) for which the zero object handle count (or class handle count)pertains. For example, in the JAVA language and virtual machineenvironment, a “zero object handle count” correlates to the lack of theexistence of any references (zero reference count) which point to thespecific object. The object is then said to be “finalizable” or exist ina finalizable state. Object handle counts (and handle counters) may bemaintained for each object in an analogous manner so that finalizable ornon-finalizable state of each particular or specific object may beknown. Class handle counts (and class handle counters) may be maintainedfor each class in an analogous manner to that for objects so thatfinalizable or non-finalizable state of each particular or specificclass may be known. Furthermore, asset handle counts or indexes andcounters may be maintained for each asset in an analogous manner to thatfor classes and objects so that finalizable or non-finalizable state ofeach particular or specific asset may be known.

Once this finalizable state has been achieved for an object (or class),the object (or class) can be safely finalized. This finalization maytypically include object (or class) deletion, removal, clean-up,reclamation, recycling, finalization or other memory freeing operationbecause the object (or class) is no longer needed.

Therefore, in light of the availability of these reference, pointer,handle count or other class and object type tracking means, the computerprogrammer (or other automated or nonautomated program generator orgeneration means) when writing a program such as the application code 50using the JAVA language and architecture, need not write any specificcode in order to provide for this class or object removal, clean up,deletion, reclamation, recycling, finalization or other memory freeingoperation. As there is only a single JAVA virtual machine 72, the singleJAVA virtual machine 72 can keep track of the class and object handlecounts in a consistent, coherent and coordinated manner, and clean up(or carry out finalization) as necessary in an automated and unobtrusivefashion, and without unwanted behaviour for example erroneous,premature, supernumerary, or re-finalization operation such as may becaused by inconsistent and/or incoherent finalization states or handlecounts. In analogous manner, a single generalized virtual machine ormachine or runtime system can keep track of the class and object handlecounts (or equivalent if the machine does not specifically use “object”and “class” designations) and clean up (or carry out finalization) asnecessary in an automated and unobtrusive fashion.

The automated handle counting system described above is used to indicatewhen an object (or class) of an executing application program 50 is nolonger needed and may be ‘deleted’ (or cleaned up, or finalized, orreclaimed, or recycled, or other otherwise freed). It is to beunderstood that when implemented in ‘non-automated memory management’languages and architectures (such as for example ‘non-garbage collected’programming languages such as C, C++, FORTRAN, COBOL, and machine-CODElanguages such as x86, SPARC, PowerPC, or intermediate-code languages),the application program code 50 or programmer (or other automated ornon-automated program generator or generation means) may be able to makethe determination at what point a specific object (or class) is nolonger needed, and consequently may be ‘deleted’ (or cleaned up, orfinalized, or reclaimed, or recycled). Thus, ‘deletion’ in the contextof this invention is to be understood to be inclusive of the deletion(or cleaning up, or finalization, or reclamation, or recycling, orfreeing) of objects (or classes) on ‘non-automated memory management’languages and architectures corresponding to deletion, finalization,clean up, recycling, or reclamation operations on those ‘non-automatedmemory management’ languages and architectures.

For a more general set of virtual machine or abstract machineenvironments, and for current and future computers and/or computingmachines and/or information appliances or processing systems, and thatmay not utilize or require utilization of either classes and/or objects,the inventive structure, method, and computer program and computerprogram product are still applicable. Examples of computers and/orcomputing machines that do not utilize either classes and/or objectsinclude for example, the x86 computer architecture manufactured by IntelCorporation and others, the SPARC computer architecture manufactured bySun Microsystems, Inc and others, the PowerPC computer architecturemanufactured by International Business Machines Corporation and others,and the personal computer products made by Apple Computer, Inc., andothers. For these types of computers, computing machines, informationappliances, and the virtual machine or virtual computing environmentsimplemented thereon that do not utilize the idea of classes or objects,the terms ‘class’ and ‘object’ may be generalized for example to includeprimitive data types (such as integer data types, floating point datatypes, long data types, double data types, string data types, characterdata types and Boolean data types), structured data types (such asarrays and records) derived types, or other code or data structures ofprocedural languages or other languages and environments such asfunctions, pointers, components, modules, structures, references andunions.

However, in the arrangement illustrated in FIG. 8, (and also in FIGS.31-33), a plurality of individual computers or machines M1, M2 . . . Mnare provided, each of which are interconnected via a communicationsnetwork 53 or other communications link and each of which individualcomputers or machines is provided with a modifier 51 (See FIG. 5) andrealised or implemented by or in for example the distributed run-timesystem (DRT) 71 (See FIG. 8) and loaded with a common application code50. The term common application program is to be understood to mean anapplication program or application program code written to operate on asingle machine, and loaded and/or executed in whole or in part on theplurality of computers or machines M1, M2 . . . Mn. Put somewhatdifferently, there is a common application program represented inapplication code 50, and this single copy or perhaps a plurality ofidentical copies are modified to generate a modified copy or version ofthe application program or program code, each copy or instance preparedfor execution on the plurality of machines. At the point after they aremodified they are common in the sense that they perform similaroperations and operate consistently and coherently with each other. Itwill be appreciated that a plurality of computers, machines, informationappliances, or the like implementing the features of the invention mayoptionally be connected to or coupled with other computers, machines,information appliances, or the like that do not implement the featuresof the invention.

In some embodiments, some or all of the plurality of individualcomputers or machines may be contained within a single housing orchassis (such as so-called “blade servers” manufactured byHewlett-Packard Development Company, Intel Corporation, IBM Corporationand others) or implemented on a single printed circuit board or evenwithin a single chip or chip set.

Essentially the modifier 51 or DRT 71, or other code modifying means isresponsible for modifying the application code 50 so that it may executeclean up or other memory reclamation, recycling, deletion orfinalization operations, such as for example finalization methods in theJAVA language and virtual machine environment, in a coordinated,coherent and consistent manner across and between the plurality ofindividual machines M1, M2, . . . , Mn. It follows therefore that insuch a computing environment it is necessary to ensure that the localobjects and classes on each of the individual machines is finalized in aconsistent fashion (with respect to the others).

It will be appreciated in light of the description provided herein thatthere are alternative implementations of the modifier 51 and thedistributed run time 71. For example, the modifier 51 may be implementedas a component of or within the distributed run time 71, and thereforethe DRT 71 may implement the functions and operations of the modifier51. Alternatively, the function and operation of the modifier 51 may beimplemented outside of the structure, software, firmware, or other meansused to implement the DRT 71. In one embodiment, the modifier 51 and DRT71 are implemented or written in a single piece of computer program codethat provides the functions of the DRT and modifier. The modifierfunction and structure therefore maybe subsumed into the DRT andconsidered to be an optional component. Independent of how implemented,the modifier function and structure is responsible for modifying theexecutable code of the application code program, and the distributed runtime function and structure is responsible for implementingcommunications between and among the computers or machines. Thecommunications functionality in one embodiment is implemented via anintermediary protocol layer within the computer program code of the DRTon each machine. The DRT may for example implement a communicationsstack in the JAVA language and use the Transmission ControlProtocol/Internet Protocol (TCP/IP) to provide for communications ortalking between the machines. Exactly how these functions or operationsare implemented or divided between structural and/or proceduralelements, or between computer program code or data structures within theinvention are less important than that they are provided.

In particular, whilst the application program code executing on oneparticular machine (say, for example machine M3) may have no activehandle, reference, or pointer to a specific local object or class (i.e.a “zero handle count”), the same application program code executing onanother machine (say for example machine M5) may have an active handle,reference, or pointer to the local similar equivalent object or classcorresponding to the ‘un-referenced’ local object or class of machineM3, and therefore this other machine (machine M5) may still need torefer to or use that object or class in future. Thus if thecorresponding similar equivalent local object or class on each machineM3 and M5 were to be finalized (or otherwise cleaned-up by some othermemory clean-up operation) in an independent and uncoordinated mannerrelative to other machine(s), the behaviour of the object andapplication as a whole is undefined—that is, in the absence ofcoordinated, coherent, and consistent finalization or memory clean-upoperations between machines M1 . . . Mn, conflict, unwantedinteractions, or other anomalous behaviour such as permanentinconsistency between local similar equivalent corresponding objects onmachine M5 and machine M3 is likely to result. For example, if the localsimilar equivalent object or class on machine M3 were to be finalized,such as by being deleted, or cleaned up, or reclaimed, or recycled, frommachine M3, in an uncoordinated and inconsistent manner with respect tomachine M5, then if machine M5 were to perform an operation on orotherwise use the local object or class corresponding to the nowfinalized similar equivalent local object on machine M3 (such operationbeing for example, in an environment with a memory updating andpropagation means of FIGS. 9, 10, 11, 12, and 13, a write to (or try towrite to) the similar equivalent local object on machine M5 or amendmentto that particular object's value), then that operation (the change orattempted change in value) could not be performed (propagated frommachine M5) throughout all the other machines M1, M2 . . . Mn since atleast the machine M3 would not include the relevant similar equivalentcorresponding particular object in its local memory, the object and itsdata, contents and value(s) having been deleted by the prior objectclean-up or finalization or reclamation or recycling operation.Therefore, even though one may contemplate machine M5 being able towrite to the object (or class) the fact that it has already beenfinalized on machine M3 means that likely such a write operation is notpossible, or at the very least not possible on machine M3.

Additionally, if an object of class on machine M3 were to be markedfinalizable and subsequently finalized (such as by being deleted, orcleaned up, or reclaimed, or recycled) whilst the same object on theother machines M1, M2 . . . Mn were not also marked as finalizable, thenthe execution of the finalization (or deletion, or clean up, orreclamation, or recycling) operation of that object on machine M3 wouldbe premature with respect to coordinated finalization operation betweenall machines M1, M2 . . . Mn, as machines other than M3 are not yetready to finalize their local similar equivalent object corresponding tothe particular object now finalized or finalizable by machine M3.Therefore were machine M3 to execute the cleanup or other finalizationroutine on a given particular object (or class), the cleanup or otherfinalization routine would preform the clean-up or finalization not justfor that local object (or class) on machine M3, but also for all similarequivalent local objects or classes (i.e. corresponding to theparticular object or class to be cleaned-up or otherwise finalized) onall other machines as well.

Were such either these circumstance to happen, the behaviour of theequivalent object on the other machines M1, M2 . . . Mn is undefined andlikely to result in permanent and irrecoverable inconsistency betweenmachine M3 and machines M1, M2 . . . Mn. Therefore, though machine M3may independently determine an object (or class) is ready forfinalization and proceed to finalize the specified object (or class),machine M5 may not have made the same determination as to the samesimilar equivalent local object (or class) being ready to be finalized,and therefore inconsistent behaviour will likely result due to thedeletion of one of the plurality of similar equivalent objects on onemachine (eg, machine M3) but not on the other machine (eg, machine M5)or machines, and the premature execution of the finalization routine ofthe specified object (or class) by machine M3 and on behalf of all othermachines M1, M2 . . . Mn. At the very least operation of machine M5 aswell as other machines in such as an above circumstance is unpredictableand would likely lead to inconsistent results, such inconsistencypotentially arising for example from, uncoordinated premature executionof the finalization routine and/or deletion of the object on one, or asubset of, machines but not others. Thus, the desirable result ofachieving or providing consistent coordinated finalization operation (orother memory clean-up operation) as required for the simultaneousoperation of the same application program code on each of the pluralityof machines M1, M2 . . . Mn would not be achieved. Any attempt thereforeto maintain identical memory contents with a memory updating andpropagation means of FIGS. 9, 10, 11, 12, and 13, or even identicalmemory contents as to a particular or defined set of classes, objects,values, or other data, for each of the machines M1, M2, . . . , Mn, asrequired for simultaneous operation of the same application program,would not be achieved given conventional schemes.

In order to ensure consistent class and object (or equivalent)finalizable status and finalization or clean up between and amongstmachines M1, M2, . . . , Mn, the application code 50 is analysed orscrutinized by searching through the executable application code 50 inorder to detect program steps (such as particular instructions orinstruction types) in the application code 50 which define or constituteor otherwise represent a finalization operation or routine (or othermemory, data, or code clean up routine, or other similar reclamation,recycling, or deletion operation). In the JAVA language, such programsteps may for example comprise or consist of some part of, or all of, a“finalize)” method of an object, and optionally any other code, routine,or method related to a ‘finalize( )’ method, for example by means of amethod invocation from the body of the ‘finalize( )’ method to adifferent method.

This analysis or scrutiny may take place either prior to loading theapplication program, or during the application program code 50 loadingprocedure, or even after the application program code 50 loadingprocedure. It may be likened to an instrumentation, programtransformation, translation, or compilation procedure in that theapplication program may be instrumented with additional instructions,and/or otherwise modified by meaning-preserving program manipulations,and/or optionally translated from an input code language to a differentcode language (such as from source-code or intermediate-code language tomachine language), and with the understanding that the term compilationnormally involves a change in code or language, for example, from sourceto object code or from one language to another language. However, in thepresent instance the term “compilation” (and its grammaticalequivalents) is not so restricted and can also include or embracemodifications within the same code or language. For example, thecompilation and its equivalents are understood to encompass bothordinary compilation (such as for example by way of illustration but notlimitation, from source-code to object-code), and compilation fromsource-code to source-code, as well as compilation from object-code toobject-code, and any altered combinations therein. It is also inclusiveof so-called “intermediary languages” which are a form of “pseudoobject-code”.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 may take place duringthe loading of the application program code such as by the operatingsystem reading the application code from the hard disk or other storagedevice or source and copying it into memory and preparing to beginexecution of the application program code. In another embodiment, in aJAVA virtual machine, the analysis or scrutiny may take place during theclass loading procedure of the java.lang.ClassLoader loadClass method(e.g., “java.lang.ClassLoader.loadClass( )”).

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading procedure,such as after the operating system has loaded the application code intomemory, or optionally even after execution of the application programcode has started, such as for example after the JAVA virtual machine hasloaded the application code into the virtual machine via the“java.lang.ClassLoader.loadClass( )” method and optionally commencedexecution.

As a consequence, of the above described analysis or scrutiny, clean uproutines are initially looked for, and when found or identified amodifying code is inserted so as to give rise to a modified clean uproutine. This modified routine is adapted and written to abort the cleanup routine on any specific machine unless the class or object (or in themore general case to be ‘asset’) to be deleted, cleaned up, reclaimed,recycled, freed, or otherwise finalized is marked for deletion by allother machines. There are several different alternative modes whereinthis modification and loading can be carried out.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 may take place duringthe loading of the application program code such as by the operatingsystem reading the application code from the hard disk or other storagedevice and copying it into memory whilst preparing to begin execution ofthe application program. In another embodiment, in a JAVA virtualmachine, the analysis or scrutiny may take place during the execution ofthe java.lang.ClassLoader loadClass (e.g.,“java.lang.ClassLoader.loadClass( )”) method.

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading proceduresuch as after the operating system has loaded the application code intomemory and even started execution, or after the java virtual machine hasloaded the application code into the virtual machine via the“java.lang.ClassLoader.loadClass( )” method. In other words, in the caseof the JAVA virtual machine, after the execution of“java.lang.ClassLoader.loadclass( )” has concluded.

Thus, in one mode, the DRT 71/1 on the loading machine, in this exampleJava Machine M1 (JVM#1), asks the DRT's 71/2, . . . , 71/n of all theother machines M2, . . . , Mn if the similar equivalent first object 50Xon all machines, say, is utilized, referenced, or in-use (i.e. notmarked as finalizable) by any other machine M2, . . . , Mn. If theanswer to this question is yes (that is, a similar equivalent object isbeing utilized by another one or more of the machines, and is not markedas finalizable and therefore not liable to be deleted, cleaned up,finalized, reclaimed, recycled, or freed), then the ordinary clean upprocedure is turned off, aborted, paused, or otherwise disabled for thesimilar equivalent first object 50X on machine JVM#1. If the answer isno, (that is the similar equivalent first object 50X on each machine ismarked as finalizable on all other machines with a similar equivalentobject 50X) then the clean up procedure is operated (or resumed orcontinued, or commenced) and the first object 50X is deleted not only onmachine JVM#1 but on all other machines M2 . . . Mn with a similarequivalent object 50X. Preferably, execution of the clean up routine isallocated to one machine, such as the last machine M1 marking thesimilar equivalent object or class as finalizable. The execution of thefinalization routine corresponding to the determination by all machinesthat the plurality of similar equivalent objects is finalizable, is toexecute only once with respect to all machines M1 . . . Mn, andpreferably by only one machine, on behalf of all machines M1 . . . Mn.Corresponding to, and preferably following, the execution of thefinalization routine, all machines may then delete, reclaim, recycle,free or otherwise clean-up the memory (and other corresponding systemresources) utilized by their local similar equivalent object.

Annexures C1, C2, C3, and C4 (also reproduced in part in Tables XVI,XVII, XVIII, and XIX below) are exemplary code listings that set forththe conventional or unmodified computer program software code (such asmay be used in a single machine or computer environment) of afinalization routine of application program 50 (Annexure C1 and TableXVI), and a post-modification excerpt of the same synchronizationroutine such as may be used in embodiments of the present inventionhaving multiple machines (Annexures C2 and C3 and Tables XVII andXVIII). Also the modified code that is added to the finalization routineis highlighted in bold text.

Annexure C1 is a before-modification excerpt of the disassembledcompiled form of the finalize( ) method of the example java applicationof Annexure C4. Annexure C2 is an after-modification form of AnnexureC1, modified by FinalLoader.java of Annexure C7 in accordance with thesteps of FIG. 22. Annexure C3 is an alternative after-modification formof Annexure C1, modified by FinalLoader.java of Annexure C7 inaccordance with the steps of FIG. 22. The modifications are highlightedin bold.

Annexure C4 is an excerpt of the source-code of the example.javaapplication used in before/after modification excerpts C1-C3. Thisexample application has a single finalization routine, the finalize( )method, which is modified in accordance with this invention byFinalLoader.java of Annexure C7.

TABLE XVI Annexure C1 - Typical prior art finalization for a singlemachine Method finalize( ) 0 getstatic #9 <Field java.io.PrintStreamout> 3 ldc #24 <String “Deleted...”> 5 invokevirtual #16 <Method voidprintln(java.lang.String)> 8 return

TABLE XVII Annexure C2 - Finalization For Multiple Machines Methodfinalize( ) 0 aload_0 1 invokestatic #3 <Method booleanisLastReference(java.lang.Object)> 4 ifne 8 7 return 8 getstatic #9<Field java.io.PrintStream out> 11 ldc #24 <String “Deleted...”> 13invokevirtual #16 <Method void println(java.lang.String)> 16 return

TABLE XVIII Annexure C3 - Finalization For Multiple Machines(Alternative) Method finalize( ) 0 aload_0 1 invokestatic #3 <Methodboolean isLastReference(java.lang.Object)> 4 ifne 8 7 return 8 getstatic#9 <Field java.io.PrintStream out> 11 ldc #24 <String “Deleted...”> 13invokevirtual #16 <Method void println(java.lang.String)> 16 return

TABLE XIX Annexure C4 - Source-code of the example.java application usedin before/after modification excer ts of Annexures C1-C3 importjava.lang.*; public class example{  /** Finalize method. */  protectedvoid finalize( ) throws Throwable{   // “Deleted...” is printed out whenthis object is garbaged.   System.out.println(“Deleted...”);  } }

It is noted that the compiled code in the annexure and portion repeatedin the table is taken from the source-code of the file “example.java”which is included in the Annexure C4. In the procedure of Annexure C1and Table XVI, the procedure name “Method finalize( )” of Step 001 isthe name of the displayed disassembled output of the finalize method ofthe compiled application code “example.java”. The method name “finalize()” is the name of an object's finalization method in accordance with theJAVA platform specification, and selected for this example to indicate atypical mode of operation of a JAVA finalization method. Overall themethod is responsible for disposing of system resources or to performother cleanup corresponding to the determination by the garbagecollector of a JAVA virtual machine that there are no more references tothis object, and the steps the “example.java” code performs aredescribed in turn.

First (Step 002), the JAVA virtual machine instruction “getstatic#9<Field java.io.PrintStream out>” causes the JAVA virtual machine toretrieve the object reference of the static field indicated by theCONSTANT_Fieldref_info constant_pool item stored in the 2^(nd) index ofthe classfile structure of the application program containing thisexample finalize( ) method and results on a reference to ajava.io.PrintStream object in the field to be placed (pushed) on thestack of the current method frame of the currently executing thread.

Next (Step 003), the JAVA virtual machine instruction “ldc #24 <String“Deleted . . . ”>” causes the JAVA virtual machine to load the Stringvalue “Deleted” onto the stack of the current method frame and resultsin the String value “Deleted” loaded onto the top of the stack of thecurrent method frame.

Next (Step 004), the JAVA virtual machine instruction “invokevirtual #16<Method void println(java.lang.String)>” causes the JAVA virtual machineto pop the topmost item off the stack of the current method frame andinvoke the “println” method, passing the popped item to the new methodframe as its first argument, and results in the “println” method beinginvoked.

Finally, the JAVA virtual machine instruction “return” (Step 005) causesthe JAVA virtual machine to cease executing this finalize( ) method byreturning control to the previous method frame and results intermination of execution of this finalize method.

As a result of these steps operating on a single machine of theconventional configurations in FIG. 1 and FIG. 2, the JAVA virtualmachine can keep track of the object handle count in a consistent,coherent and coordinated manner, and in executing the finalize( ) methodcontaining the println operation is able to ensure that unwantedbehaviour (for example premature or supernumerary finalization operationsuch as execution of the finalize( ) method of a single ‘example.java’object more than once) such as may be caused by inconsistent and/orincoherent finalization states or handle counts, does not occur. Werethese steps to be carried out on the plurality of machines of theconfigurations of FIG. 5 and FIG. 8 with the memory update andpropagation replication means of FIGS. 9, 10, 11, 12, and 13, andconcurrently executing the application program code 50 on each one ofthe plurality of machines M1 . . . Mn, the finalization operations ofeach concurrently executing application program occurrence on each ofthe one of the machines would be performed without coordination betweenany other of the occurrences on any other of the machine(s). Given thedesirable result of consistent, coordinated and coherent finalizationoperation across a plurality of a machines, this prior art arrangementwould fail to perform such consistent coordinated finalization operationacross the plurality of machines, as each machine performs finalizationonly locally and without any attempt to coordinate their localfinalization operation with any other similar finalization operation onany one or more other machines. Such an arrangement would therefore besusceptible to unwanted or other anomalous behaviour due touncoordinated, inconsistent and/or incoherent finalization states orhandle counts, and associated finalization operation. Therefore it isdesirable to overcome this limitation of the prior art arrangement.

In the exemplary code in Table XVIII (Annexure C3), the code has beenmodified so that it solves the problem of consistent, coordinatedfinalization operation for a plurality of machines M1 . . . Mn, that wasnot solved in the code example from Table XVI (Annexure C1). In thismodified finalize( ) method code, an “aload_(—)0” instruction isinserted before the “getstatic #9” instruction in order to be the firstinstruction of the finalize) method. This causes the JAVA virtualmachine to load the item in the local variable array at index 0 of thecurrent method frame and store this item on the top of the stack of thecurrent method frame, and results in the object reference of the ‘this’object at index 0 being pushed onto the stack.

Furthermore, the JAVA virtual machine instruction “invokestatic#3<Method boolean isLastReference(java.lang.Object)>” is inserted afterthe “0 aload_(—)0” instruction so that the JAVA virtual machine pops thetopmost item off the stack of the current method frame (which inaccordance with the preceding “aload_(—)0” instruction is a reference tothe object to which this finalize( ) method belongs) and invokes the“isLastReference” method, passing the popped item to the new methodframe as its first argument, and returning a boolean value onto thestack upon return from this “invokestatic” instruction. This change issignificant because it modifies the finalize( ) method to execute the“isLastReference” method and associated operations, corresponding to thestart of execution of the finalize( ) method, and returns a booleanargument (indicating whether the object corresponding to this finalize() method is the last remaining reference amongst the similar equivalentobject on each of the machines M1 . . . Mn) onto the stack of theexecuting method frame of the finalize( ) method.

Next, two JAVA virtual machine instructions “ifne 8” and “return” areinserted into the code stream after the “1 invokestatic #3” instructionand before the “getstatic #9” instruction. The first of these twoinstructions, the “ifne 8” instruction, causes the JAVA virtual machineto pop the topmost item off the stack and performs a comparison betweenthe popped value and zero. If the performed comparison succeeds (i.e. ifand only if the popped value is not equal to zero), then executioncontinues at the “8 getstatic #9” instruction. If however the performedcomparison fails (i.e. if and only if the popped value is equal tozero), then execution continues at the next instruction in the codestream, which is the “7 return” instruction. This change is particularlysignificant because it modifies the finalize( ) method to eithercontinue execution of the finalize( ) method (i.e. instructions 8-16) ifthe returned value of the “isLastReference” method was positive (i.e.“true”), or discontinue execution of the finalize( ) method (i.e. the “7return” instruction causing a return of control to the invoker of thisfinalize( ) method) if the returned value of the “isLastReference”method was negative (i.e. “false”).

The method void isLastReference(java.lang.Object), part of theFinalClient code of Annexure C5 and part of the distributed runtimesystem (DRT) 71, performs the communications operations between machinesM1 . . . Mn to coordinate the execution of the finalize( ) methodamongst the machines M1 . . . Mn. The isLastReference method of thisexample communicates with the InitServer code of Annexure C6 executingon a machine X of FIG. 15, by means of sending an “clean-up statusrequest” to machine X corresponding to the object being “finalized”(i.e. the object to which this finalize( ) method belongs). Withreference to FIG. 25 and Annexure C6, machine X receives the “clean-upstatus request” corresponding to the object to which the finalize( )method belongs, and consults a table of clean-up counts or finalizationstates to determine the clean-up count or finalization state for theobject to which the request corresponds.

If the plurality of similar equivalent objects one each one of theplurality of machines M1 . . . Mn corresponding to the clean-up statusrequest is marked for clean-up on all other machines than the requestingmachine (i.e. n−1 machines), then machine X will send a responseindicating that the plurality of similar equivalent objects are markedfor clean-up on all other machines, and optionally update a record entrycorresponding to the specified similar equivalent objects to indicatethe similar equivalent objects as now cleaned up. Alternatively, if theplurality of the similar equivalent objects corresponding to theclean-up status request is not marked for clean-up on all other machinesthan the requesting machine (i.e. less than n−1 machines), then machineX will send a response indicating that the plurality of similarequivalent objects is not marked for cleanup on all other machines, andincrement the “marked for clean-up counter” record (or other similarfinalization record means) corresponding to the specified object, torecord that the requesting machine has marked its one of the pluralityof similar equivalent objects to be cleaned-up. Corresponding to thedetermination that the plurality of similar equivalent objects to whichthis clean-up status request pertains is marked for clean-up on allother machines than the requesting machine, a reply is generated andsent to the requesting machine indicating that the plurality of similarequivalent objects is marked for clean-up on all other machines than therequesting machine. Additionally, and optionally, machine X may updatethe entry corresponding to the object to which the clean-up statusrequest pertained to indicate the plurality of similar equivalentobjects as now “cleaned-up”. Following a receipt of such a message frommachine X indicating that the plurality of similar equivalent objects ismarked for clean-up on all other machines, the isLastReference( ) methodand operations terminate execution and return a ‘true’ value to theprevious method frame, which is the executing method frame of thefinalize( ) method. Alternatively, following a receipt of a message frommachine X indicating that the plurality of similar equivalent objects isnot marked for clean-up on all other machines, the isLastReference( )method and operations terminate execution and return “false” value tothe previous method frame, which is the executing method frame of thefinalize( ) method. Following this return operation, the execution ofthe finalize( ) method frame then resumes as indicated in the codesequence of Annexure C3.

It will be appreciated that the modified code permits, in a distributedcomputing environment having a plurality of computers or computingmachines, the coordinated operation of finalization routines or otherclean-up operations so that the problems associated with the operationof the unmodified code or procedure on a plurality of machines M1 . . .Mn (such as for example erroneous, premature, multiple finalization, orre-finalization operation) does not occur when applying the modifiedcode or procedure.

It may be observed that the code in Annexure C2 and Table XVII is analternative but lesser preferred form of the code in Annexure C3. It isessentially functionally equivalent to the code and approach in AnnexureC3.

As seen in FIG. 15 a modification to the general arrangement of FIG. 8is provided in that machines M1, M2, . . . , Mn are as before and runthe same application code 50 (or codes) on all machines M1, M2, . . . ,Mn simultaneously or concurrently. However, the previous arrangement ismodified by the provision of a server machine X which is convenientlyable to supply housekeeping functions, for example, and especially theclean up of structures, assets and resources. Such a server machine Xcan be a low value commodity computer such as a PC since itscomputational load is low. As indicated by broken lines in FIG. 15, twoserver machines X and X+1 can be provided for redundancy purposes toincrease the overall reliability of the system. Where two such servermachines X and X+1 are provided, they are preferably operated asredundant machines in a failover arrangement.

It is not necessary to provide a server machine X as its computationalload can be distributed over machines M1, M2, . . . , Mn. Alternatively,a database operated by one machine (in a master/slave type operation)can be used for the housekeeping function(s).

FIG. 16 shows a preferred general procedure to be followed. Afterloading 161 has been commenced, the instructions to be executed areconsidered in sequence and all clean up routines are detected asindicated in step 162. In the JAVA language these are the finalizationroutines or finalize method (e.g., “finalize( )”). Other languages usedifferent terms.

Where a clean up routine is detected, it is modified at step 163 inorder to perform consistent, coordinated, and coherent clean up orfinalization across and between the plurality of machines M1, M2 . . .Mn, typically by inserting further instructions into the clean uproutine to, for example, determine if the object (or class or otherasset) containing this finalization routine is marked as finalizableacross all similar equivalent local objects on all other machines, andif so performing finalization by resuming the execution of thefinalization routine, or if not then aborting the execution of thefinalization routine, or postponing or pausing the execution of thefinalization routine until such a time as all other machines have markedtheir similar equivalent local objects as finalizable. Alternatively,the modifying instructions could be inserted prior to the routine. Oncethe modification has been completed the loading procedure continues byloading modified application code in place of the unmodified applicationcode, as indicated in step 164. Altogether, the finalization routine isto be executed only once, and preferably by only one machine, on behalfof all machines M1 . . . Mn corresponding to the determination by allmachines M1 . . . Mn that the particular object is finalizable.

FIG. 17 illustrates a particular form of modification. Firstly, thestructures, assets or resources (in JAVA termed classes or objects) 50A,50X . . . 50Y which are possible candidates to be cleaned up, areallocated a name or tag (for example a global name or tag), or havealready been allocated a global name or tag, which can be used toidentify corresponding similar equivalent local structures, assets, orresources (such as classes and objects in JAVA) globally on each of themachines M1, M2 . . . Mn, as indicated by step 172. This preferablyhappens when the classes or objects are originally initialized. This ismost conveniently done via a table maintained by server machine X. Thistable also includes the “clean up status” of the class or object (orother asset). It will be understood that this table or other datastructure may store only the clean up status, or it may store otherstatus or information as well. In one embodiment, this table alsoincludes a counter which stores a machine asset deletion count valueidentifying the number of machines (and optionally the identity of themachines although this is not required) which have marked thisparticular object, class, or other asset for deletion. In oneembodiment, the count value is incremented until the count value equalsthe number of machines. Thus a total machine asset deletion count valueof less than (n−1), where n is the total number of machines in Mnindicates a “do not clean up” status for the object, class, or otherasset as a network (or machine constellation) whole, because the machineasset deletion count of less than n−1 means that one or more machineshave yet to mark their similar equivalent local object (or class orother asset) as finalizable and that object cannot be cleaned up asunwanted or other anomalous behaviour may result. Stated differently,and by way of example but not limitation, if there are six machines andthe asset deletion count is less than five then it means that not allthe other machines have attempted to finalize this object (i.e., not yetmarked this object as finalizable), and therefore the object can't befinalised. If however the asset deletion count is five, then it meansthat there is only one machine that has yet to attempt to finalize thisobject (i.e., mark this object as finalizable) and therefore that lastmachine yet to mark the object as finalizable must be the currentmachine attempting to finalize the object (i.e., marking the object asfinalizable and consequently consulting the finalization table as tofinalization status of this object on all other machines). In theconfiguration of six machines, the count value of n−1=5 means that fivemachines must have previously marked the object for deletion and thesixth machine to mark this object for deletion is the machine thatactually executes the full finalization routine.

As indicated in FIG. 17, if the global name or identifier is not markedfor cleanup or deletion or other finalization on all other machines(i.e., all except on the machine proposing to carry out the clean up ordeletion routine) then this means that the proposed clean up orfinalization routine of the object or class (or other asset) should beaborted, stopped, suspend, paused, postponed, or cancelled prior to itsinitiation or if already initiated then to its completion if it hasalready begun execution, since the object or class is still required byone or more of the machines M1, M2 . . . Mn, as indicated by step 175.

In one embodiment, the clean up or finalization routine is stopped frominitiating or beginning execution; however, if some implementations itis difficult or practically impossible to stop the clean up orfinalization routine from initiating or beginning execution. Therefore,in an alternative embodiment, the execution of the finalization routinethat has already started is aborted such that it does not complete ordoes not complete in its normal manner. This alternative abortion isunderstood to include an actual abortion, or a suspend, or postpone, orpause of the execution of a finalization routine that has started toexecute (regardless of the stage of execution before completion) andtherefore to make sure that the finalization routine does not get thechance to execute to completion to clean up the object (or class orother asset), and therefore the object (or class or other asset) remains“uncleaned” (i.e., “unfinalised”, or “not deleted”).

However or alternatively, if the global name or other unique number oridentifier for a plurality of similar equivalent local objects each onof the plurality of machines M1, M2 . . . Mn is marked for deletion onall other machines, this means that no other machine requires the classor object (or other asset) corresponding to the global name or otherunique number or identifier. As a consequence clean up routine andoperation, or optionally the regular or conventional ordinary clean uproutine and operation, indicated in step 176 can be, and should be,carried out.

FIG. 18 shows the enquiry made by the machine proposing to execute aclean up routine (one of M1, M2 . . . Mn) to the server machine X. Theoperation of this proposing machine is temporarily interrupted, as shownin step 181 and 182, and corresponding to step 173 of FIG. 17. In step181 the proposing machine sends an enquiry message to machine X torequest the clean-up or finalization status of the object (or class orother asset) to be cleaned-up. Next, the proposing machine awaits areply from machine X corresponding to the enquiry message sent by theproposing machine at step 181, indicated by step 182.

FIG. 25 shows the activity carried out by machine X in response to sucha finalization or clean up status enquiry of step 181 in FIG. 18. Thefinalization or clean up status is determined as seen in step 192 whichdetermines if the object (or class or other asset) corresponding to theclean-up status request of global name, as received at step 191 (191A),is marked for deletion on all other machines other than the enquiringmachine 181 from which the clean-up status request of step 191originates. The singular term object or class as used in this document(or the equivalent term of asset, or resource used in step 192 (192A)and other Figures) are to be understood to be inclusive of all similarequivalent objects (or classes, or assets, or resources) correspondingto the same global name on each of the plurality of machines M1, M2, . .. , Mn. If the step 193 (193A) determination is made that determinesthat the global named resource is not marked (“No”) for deletion on(n−1) machines (i.e. is utilized elsewhere), then a response to thateffect is sent to the enquiring machine 194 (194A) but the “marked fordeletion” counter is incremented by one (1), as shown by step 197(197A). Similarly, if the answer to this determination is marked fordeletion (“Yes”) indicating that the global named resource is marked fordeletion on all other machines other than the waiting enquiring machine182 then a corresponding reply is sent to the waiting enquiring machine182 from which the clean-up status request of step 191 originated asindicated by step 195 (195A). The waiting enquiring machine 182 is thenable to respond accordingly, such as for example by: (i) aborting (orpausing, or postponing) execution of the finalization routine when thereply from machine X of step 182 indicated that the similar equivalentlocal objects on the plurality of machines M1, M2, . . . , Mncorresponding to the global name of the object proposed to be finalizedof step 172 is still utilized elsewhere (i.e., not marked for deletionon all other machines other than the machine proposing to carry outfinalization); or (ii) by continuing (or resuming, or starting)execution of the finalization routine when the reply from machine X ofstep 182 indicated that the similar equivalent local objects on theplurality of machines M1, M2 . . . Mn corresponding to the global nameof the object proposed to be finalized of step 172 are not utilizedelsewhere (i.e., marked for deletion on all other machines other thanthe machine proposing to carry out finalization). As indicated by brokenlines in FIG. 25, preferably in addition to the “yes” response shown instep 195, the shared table or cleaned-up statuses stored or maintainedon machine X is updated so that the status of the globally named assetis changed to “cleaned up” as indicated by step 196.

Reference is made to the accompanying Annexure C in which: Annexure C1is a typical code fragment from an unmodified finalize routine, AnnexureC2 is an equivalent in respect of a modified finalize routine, andAnnexure C3 is an alternative equivalent in respect of a modifiedfinalize routine.

Annexures C1 and C2/C3 repeated as Tables XVI and XVII/XVIII are thebefore (pre-modification or unmodified code) and after (orpost-modification or modified code) excerpt of a finalization routinerespectively. The modified code that is added to the method ishighlighted in bold. In the original code sample of Annexure C1, thefinalize method prints “Deleted . . . ” to the computer console on eventof finalization (i.e. deletion) of this object. Thus, without managementof object finalization in a distributed environment, each machine wouldre-finalize the same object, thus executing the finalize method morethan once for a single globally-named coherent plurality of similarequivalent objects. Clearly this is not what the programmer or user of asingle application program code instance expects to happen.

So, taking advantage of the DRT, the application code 50 is modified asit is loaded into the machine by changing the clean-up, deletion, orfinalization routine or method. It will be appreciated that the termfinalization is typically used in the context of the JAVA languagerelative to the JAVA virtual machine specification existent at the dateof filing of this specification. Therefore, finalization refers toobject and/or class cleanup or deletion or reclamation or recycling orany equivalent form of object, class, asset or resource clean-up in themore general sense. The term finalization should therefore be taken inthis broader meaning unless otherwise restricted. The changes made(highlighted in bold) are the initial instructions that the finalizemethod executes. These added instructions check if this particularobject is the last remaining object of the plurality of similarequivalent objects on the plurality of machines M1, M2 . . . Mn to bemarked as finalizable, by calling a routine or procedure to determinethe clean-up status of the object to be finalized, such as the“isLastReference( )” procedure or method of a DRT 71 performing thesteps of 172-176 of FIG. 17 where the determination as to the clean-upstatus of the particular object is sought, and which determines either atrue result or a false result corresponding to whether or not thisparticular object on this particular machine that is executing thedetermination procedure is the last of the plurality of machines M1, M2. . . Mn, each with one of a similar equivalent peer object, to requestfinalization. Recall that a peer object refers to a similar equivalentobject on a different one of the machines, so that for example, in aconfiguration having eight machines, there will be eight peer objects(i.e. eight similar equivalent objects each on one of eight machines).

The finalization determination procedure or method “isLastReference( )”of the DRT 71 can optionally take an argument which represents a uniqueidentifier for this object (See Annexure C3 and Table XVIII). Forexample, the name of the object that is being considered forfinalization, a reference to the object in question being considered forfinalization, or a unique number or identifier representing this objectacross all machines (or nodes), to be used in the determination of thefinalization status of this object or class or other asset. This way,the DRT can support the finalization of multiple objects (or classes orassets) at the same time without becoming confused as to which of themultiple objects are already finalized and which are not, by using theunique identifier of each object to consult the correct record in thefinalization table referred to earlier.

The DRT 71 can determine the finalization state of the object in anumber of possible ways. Preferably, it (the requesting machine) can askeach other requested machine in turn (such as by using a computercommunications network to exchange query and response messages betweenthe requesting machine and the requested machine(s) if their requestedmachine's similar equivalent object has been marked for finalization,and if any requested machine replies false indicating that their similarequivalent object is not marked for finalization, then return a falseresult at return from the “isLastReference( )” method indicating thatthe local similar equivalent object should not be finalized, otherwisereturn a true result at return from the “isLastReference( )” methodindicating that the local similar equivalent object can be finalized. Ofcourse different logic schemes for true or false result mayalternatively be implemented with the same effect. Alternatively, theDRT 71 on the local machine can consult a shared record table (perhapson a separate machine (e.g., machine X), or a coherent shared recordtable on each local machine and updated to remain substantiallyidentical, or in a database) to determine if each of the plurality ofsimilar equivalent objects have been marked for finalization by allrequested machines except the current requesting machine.

If the “isLastReference( )” method of the DRT 71 returns true then thismeans that this object has been marked for finalization on all othermachines in the virtual or distributed computing environment (i.e. theplurality of machines M1 . . . Mn), and hence, the execution of thefinalize method is to proceed as this is considered the last remainingsimilar equivalent object on the plurality of machines M1, M2 . . . Mnto be marked or declared as finalizable.

On the other hand, if the “isLastReference( )” method of the DRT 71returns false, then this means that the plurality of similar equivalentobjects has not been marked for finalization by all other machines inthe distributed environment, as recorded in the shared record table onmachine X of the finalization states of objects. In such a case, thefinalize method is not to be executed (or alternatively resumed, orcontinued), as it will potentially invalidate the object on thosemachine(s) that are continuing to use their similar equivalent objectand have yet to mark their similar equivalent object for finalization.Thus, when the DRT returns false, the inserted four instructions at thestart of the finalize method prevent execution of the remaining code ofthe finalize method by aborting the execution of the finalize methodthrough the use of a return instruction, and consequently aborting theJava Virtual Machine's finalization operation for this object.

Given the fundamental concept of testing to determine if a finalization,such as a deletion or clean up, is ready to be carried out on a class,object, or other asset; and if ready carrying out the finalization, andif not ready, then not carrying out the finalization, there are severaldifferent ways or embodiments in which this finalization concept,method, and procedure may be implemented.

In the first embodiment, a particular machine, say machine M2, loads theasset (such as class or object) inclusive of a clean up routine modifiesit, and then loads each of the other machines M1, M3, . . . , Mn (eithersequentially or simultaneously or according to any other order, routine,or procedure) with the modified object (or class or asset) inclusive ofthe now modified clean up routine or routines. Note that there may beone or a plurality of routines corresponding to only one object in theapplication code or there can be a plurality of routines correspondingto a plurality of objects in the application code. Note that in oneembodiment, the cleanup routine(s) that is (are) loaded is binaryexecutable object code. Alternatively, the cleanup routine(s) that is(are) loaded is executable intermediate code.

In one arrangement, which may be termed “master/slave” (orprimary/secondary) each of the slave (or secondary) machines M1, M3, . .. , Mn loads the modified object (or class), and inclusive of the nowmodified clean-up routine(s), that was sent to it over the computercommunications network or other communications link or path by themaster (or primary) machine, such as machine M2, or some other machinesuch as a machine X of FIG. 15. In a slight variation of this“master/slave” or “primary/secondary” arrangement, the computercommunications network can be replaced by a shared storage device suchas a shared file system, or a shared document/file repository such as ashared database.

Note that the modification performed on each machine or computer neednot and frequently will not be the same or identical. What is requiredis that they are modified in a similar enough way that in accordancewith the inventive principles described herein, each of the plurality ofmachines behaves consistently and coherently relative to the othermachines to accomplish the operations and objectives described herein.Furthermore, it will be appreciated in light of the description providedherein that there are a myriad of ways to implement the modificationsthat may for example depend on the particular hardware, architecture,operating system, application program code, or the like or differentfactors. It will also be appreciated that embodiments of the inventionmay be implemented within an operating system, outside of or without thebenefit of any operating system, inside the virtual machine, in anEPROM, in software, in firmware, or in any combination of these.

In a further variation of this “master/slave” or “primary/secondary”arrangement, machine M2 loads the asset (such as class or object)inclusive of a cleanup routine in unmodified form on machine M2, andthen (for example, M2 or each local machine) deletes the unmodifiedclean up routine that had been present on the machine in whole or partfrom the asset (such as class or object) and loads by means of acomputer communications network the modified code for the asset with thenow modified or deleted clean up routine on the other machines. Thus inthis instance the modification is not a transformation, instrumentation,translation or compilation of the asset clean up routine but a deletionof the clean up routine on all machines except one. In one embodiment,the actual code-block of the finalization or cleanup routine is deletedon all machines except one, and this last machine therefore is the onlymachine that can execute the finalization routine because all othermachines have deleted the finalization routine. One benefit of thisapproach is that no conflict arises between multiple machines executingthe same finalization routine because only one machine has the routine.

The process of deleting the clean up routine in its entirety can eitherbe performed by the “master” machine (such as machine M2 or some othermachine such as machine X of FIG. 15) or alternatively by each othermachine M1, M3 . . . Mn upon receipt of the unmodified asset. Anadditional variation of this “master/slave” or “primary/secondary”arrangement is to use a shared storage device such as a shared filesystem, or a shared document/file repository such as a shared databaseas means of exchanging the code for the asset, class or object betweenmachines M1, M2 . . . Mn and optionally a machine X of FIG. 15.

In a still further embodiment, each machine M1, . . . , Mn receives theunmodified asset (such as class or object) inclusive of finalization orclean up routine(s), but modifies the routine(s) and then loads theasset (such as class or object) consisting of the now modifiedroutine(s). Although one machine, such as the master or primary machinemay customize or perform a different modification to the finalization orclean up routine(s) sent to each machine, this embodiment more readilyenables the modification carried out by each machine to be slightlydifferent and to be enhanced, customized or optimized based upon itsparticular machine architecture, hardware, processor, memory,configuration, operating system or other factors, yet still similar,coherent and consistent with other machines with all other similarmodifications and characteristics that may not need to be similar oridentical.

In a further arrangement, a particular machine, say M1, loads theunmodified asset (such as class or object) inclusive of a finalizationor clean up routine and all other machines M2, M3, . . . , Mn perform amodification to delete the clean up routine of the asset (such as classor object) and load the modified version.

In all of the described instances or embodiments, the supply orcommunication of the asset code (such as class code or object code) tothe machines M1, . . . , Mn, and optionally inclusive of a machine X ofFIG. 15 can be branched, distributed or communicated among and betweenthe different machines in any combination or permutation; such as byproviding direct machine to machine communication (for example, M2supplies each of M1, M3, M4, etc directly), or by providing or usingcascaded or sequential communication (for example, M2 supplies M1 whichthen supplies M3, which then supplies M4, and so on), or a combinationof the direct and cascaded and/or sequential.

In a still further arrangement, the machines M1, . . . , Mn, may sendsome or all load requests to an additional machine X (See for examplethe embodiment of FIG. 15), which performs the modification to theapplication program code 50 (such as consisting of assets, and/orclasses, and/or objects) and inclusive of finalization or clean uproutine(s), via any of the afore mentioned methods, and returns themodified application program code inclusive of the now modifiedfinalization or clean-up routine(s) to each of the machines M1 to Mn,and these machines in turn load the modified application program codeinclusive of the modified routine(s) locally. In this arrangement,machines M1 to Mn forward all load requests to machine X, which returnsa modified application program code inclusive of modified finalizationor clean-up routine(s) to each machine. The modifications performed bymachine X can include any of the modifications covered under the scopeof the present invention. This arrangement may of course be applied tosome of the machines and other arrangements described herein beforeapplied to other of the machines.

Persons skilled in the computing arts will be aware of various possibletechniques that may be used in the modification of computer code,including but not limited to instrumentation, program transformation,translation, or compilation means.

One such technique is to make the modification(s) to the applicationcode, without a preceding or consequential change of the language of theapplication code. Another such technique is to convert the original code(for example, JAVA language source-code) into an intermediaterepresentation (or intermediate-code language, or pseudo code), such asJAVA byte code. Once this conversion takes place the modification ismade to the byte code and then the conversion may be reversed. Thisgives the desired result of modified JAVA code.

A further possible technique is to convert the application program tomachine code, either directly from source-code or via the abovementionedintermediate language or through some other intermediate means. Then themachine code is modified before being loaded and executed. A stillfurther such technique is to convert the original code to anintermediate representation, which is thus modified and subsequentlyconverted into machine code.

The present invention encompasses all such modification routes and alsoa combination of two, three or even more, of such routes.

Synchronization

Turning again to FIG. 14, there is illustrated a schematicrepresentation of a single prior art computer operated as a JAVA virtualmachine. In this way, a machine (produced by any one of variousmanufacturers and having an operating system operating in any one ofvarious different languages) can operate in the particular language ofthe application program code 50, in this instance the JAVA language.That is, a JAVA virtual machine 72 is able to operate application code50 in the JAVA language, and utilize the JAVA architecture irrespectiveof the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment,the generalized platform, and/or virtual machine and/or machine and/orruntime system is able to operate application code 50 in the language(s)(possibly including for example, but not limited to any one or more ofsource-code languages, intermediate-code languages, object-codelanguages, machine-code languages, and any other code languages) of thatplatform, and/or virtual machine and/or machine and/or runtime systemenvironment, and utilize the platform, and/or virtual machine and/ormachine and/or runtime system and/or language architecture irrespectiveof the machine manufacturer and the internal details of the machine. Itwill also be appreciated in light of the description provided hereinthat platform and/or runtime system may include virtual machine andnon-virtual machine software and/or firmware architectures, as well ashardware and direct hardware coded applications and implementations.

Furthermore, the single machine (not a plurality of connected or coupledmachines) of FIG. 14, or a more general virtual machine or abstractmachine environment such as for example but not limited to anobject-oriented virtual machine, is able to readily ensure that multipledifferent and potentially concurrent uses of specific objects 50X-50Z donot conflict or cause unwanted interactions, when specified by the useof mutual exclusion (e.g. “mutex”) operators or operations (inclusivefor example of locks, semaphores, monitors, barriers, and the like),such as for example by the programmer's use of a synchronizing orsynchronization routine in a computer program written in the JAVAlanguage. As each object exists singularly and only locally (that islocally within the machine within which execution is occurring) in thisexample, the single JAVA virtual machine 72 of FIG. 14 executing withinthis single machine is able to ensure that an object (or severalobjects) is (are) properly synchronized as defined by the JAVA VirtualMachine and Language Specifications existent at least as of the date ofthe filing of this patent application, when specified to do so by theapplication program (or programmer), and thus the object or objects tobe synchronized are only utilized by one executing part of potentiallymultiple executing parts and potentially concurrently executing parts ofthe executable application code 50 at once or at the same time, such asfor example potentially concurrently executing threads or processes. Ifanother executing part and potentially concurrently executing part (suchas for example but not limited to a potentially concurrently executingthread or process) of the executable application code 50 wishes toexclusively use the same object whilst that object is the subject of amutual exclusion operation by a first executing part (e.g. a firstthread or process), such as when a second executing part (e.g. a secondthread or process) of a multiple part processing machine of FIG. 14attempts to synchronize on a same object already synchronized by a firstexecuting part, then the possible conflict is resolved by the JAVAvirtual machine 72 such that the second and additional executing partsand potentially concurrently executing part or parts of the applicationprogram 50 have to wait until the first executing part has finished theexecution of its synchronization routine or other mutual exclusionoperation. It may be appreciated that in a conventional situation, asecond or multiple executing part(s) (i.e. a second or multiplethread(s)) of the application program or program code may want to usethe same object in a multiple-thread processing machine of FIG. 14.

For a more general set of virtual machine or abstract machineenvironments, and for current and future computers and/or computingmachines and/or information appliances or processing systems, and thatmay not utilize or require utilization of either classes and/or objects,the inventive structure, method, and computer program and computerprogram product are still applicable. Examples of computers and/orcomputing machines that do not utilize either classes and/or objectsinclude for example, the x86 computer architecture manufactured by IntelCorporation and others, the SPARC computer architecture manufactured bySun Microsystems, Inc and others, the PowerPC computer architecturemanufactured by International Business Machines Corporation and others,and the personal computer products made by Apple Computer, Inc., andothers. For these types of computers, computing machines, informationappliances, and the virtual machine or virtual computing environmentsimplemented thereon that do not utilize the idea of classes or objects,the terms ‘class’ and ‘object’ may be generalized for example to includeprimitive data types (such as integer data types, floating point datatypes, long data types, double data types, string data types, characterdata types and Boolean data types), structured data types (such asarrays and records) derived types, or other code or data structures ofprocedural languages or other languages and environments such asfunctions, pointers, components, modules, structures, references andunions.

A similar procedure applies mutatis mutandis (that is, with suitable ornecessary alterations) for classes 50A. In particular, the computerprogrammer (or if and when applicable, an automated or nonautomatedcomputer program generator or generation means) when writing orgenerating a program using the JAVA language and architecture in asingle machine, need only use a synchronization routine or routines inorder to provide for this avoidance of conflict or unwanted interaction.Thus a single JAVA virtual machine can keep track of exclusiveutilization of the classes and objects (or other asset) and avoidcorresponding problems (such as conflict, race condition, unwantedinteraction, or other anomalous behaviour due to unexpected criticaldependence on the relative timing of events) as necessary in anunobtrusive fashion. The process whereby only one object or class isexclusively used is termed “synchronization” in the JAVA language. Inthe JAVA language, synchronization may usually be operationalized orimplemented in one of three ways or means. The first way or means isthrough the use of a synchronization method description that is includedin the source-code of an application program written in the JAVAlanguage. The second way or means is by the inclusion of a‘synchronization descriptor’ in the method descriptor of a compiledapplication program of the JAVA virtual machine. And the third way ormeans for performing synchronization are by the use of the instructionsmonitor enter (e.g., “monitorenter”) and monitor exit (e.g.,“monitorexit”) of the JAVA virtual machine which signify respectivelythe beginning and ending of a synchronization routine which results inthe acquiring or execution of a “lock” (or other mutual exclusionoperator or operation), and the releasing or termination of a “lock” (orother mutual exclusion operator or operation) respectively whichprevents an asset being the subject of conflict (or race condition, orunwanted interaction, or other anomalous behaviour due to unexpectedcritical dependence on the relative timing of events) between multipleand potentially concurrent uses. An asset may for example include aclass or an object, as well as any othersoftware/language/runtime/platform/architecture or machine resource.Such resources may include for example, but are not limited to, softwareprograms (such as for example executable software. modules, subprograms,sub-modules, application program interfaces (API), software libraries,dynamically linkable libraries) and data (such as for example datatypes, data structures, variables, arrays, lists, structures, unions),and memory locations (such as for example named memory locations, memoryranges, address space(s), registers,) and input/output (I/O) portsand/or interfaces, or other machine, computer, or information applianceresource or asset.

However, in the arrangement illustrated in FIG. 8, (and also in FIGS.31-33), a plurality of individual computers or machines M1, M2, . . . ,Mn are provided, each of which are interconnected via a communicationsnetwork 53 or other communications link and each of which individualcomputers or machines is provided with a modifier 51 (See in FIG. 5) andrealised by or in for example the distributed run time (DRT) 71 (SeeFIG. 8) and loaded with a common application code 50. The term commonapplication program is to be understood to mean an application programor application program code written to operate on a single machine, andloaded and/or executed in whole or in part on each one of the pluralityof computers or machines M1, M2 . . . Mn, or optionally on each one ofsome subset of the plurality of computers or machines M1, M2 . . . Mn.Put somewhat differently, there is a common application programrepresented in application code 50, and this single copy or perhaps aplurality of identical copies are modified to generate a modified copyor version of the application program, each copy or instance preparedfor execution on the plurality of machines. At the point after they aremodified they are common in the sense that they perform similaroperations and operate consistently and coherently with each other. Itwill be appreciated that a plurality of computers, machines, informationappliances, or the like implementing the features of the invention mayoptionally be connected to or coupled with other computers, machines,information appliances, or the like that do not implement the featuresof the invention.

In some embodiments, some or all of the plurality of individualcomputers or machines may be contained within a single housing orchassis (such as so-called “blade servers” manufactured byHewlett-Packard Development Company, Intel Corporation, IBM Corporationand others) or implemented on a single printed circuit board or evenwithin a single chip or chip set.

Essentially the modifier 51 or DRT 71 ensures that when an executingpart (such as a thread or process) of the modified application program50 running on one or more of the machines exclusively utilizes (e.g., bymeans of a synchronization routine or similar or equivalent mutualexclusion operator or operation) a particular local asset, such as anobjects 50X-50Z or class 50A, no other executing part and potentiallyconcurrently executing part on machines M2 . . . Mn exclusively utilizesthe similar equivalent corresponding asset in its local memory at onceor at the same time.

It will be appreciated in light of the description provided herein thatthere are alternative implementations of the modifier 51 and thedistributed runtime system 71. For example, the modifier 51 may beimplemented as a component of or within the distributed run time 71, andtherefore the DRT 71 may implement the functions and operations of themodifier 51. Alternatively, the function and operation of the modifier51 may be implemented outside of the structure, software, firmware, orother means used to implement the DRT 71. In one embodiment, themodifier 51 and DRT 71 are implemented or written in a single piece ofcomputer program code that provides the functions of the DRT andmodifier. The modifier function and structure therefore maybe subsumedinto the DRT and considered to be an optional component. Independent ofhow implemented, the modifier function and structure is responsible formodifying the executable code of the application code program, and thedistributed run time function and structure is responsible forimplementing communications between and among the computers or machines.The communications functionality in one embodiment is implemented via anintermediary protocol layer within the computer program code of the DRTon each machine. The DRT may for example implement a communicationsstack in the JAVA language and use the Transmission ControlProtocol/Internet Protocol (TCP/IP) to provide for communications ortalking between the machines. Exactly how these functions or operationsare implemented or divided between structural and/or proceduralelements, or between computer program code or data structures within theinvention are less important than that they are provided.

It will therefore be understood in light of the description providedhere that the invention further includes any means of implementingthread-safety, regardless of whether it is through the use of locks(lock/unlock), synchronizations, monitors, semphafores, mutexes, orother mechanisms.

It will be appreciated that synchronization means or implies “exclusiveuse” or “mutual exclusion” of an asset or resource. Conventionalstructures and methods for implementations of single computers ormachines have developed some methods for synchronization on such singlecomputer or machine configurations. However, these conventionalstructures and methods have not provided solutions for synchronizationbetween and among a plurality of computers, machines, or informationappliances.

In particular, whilst one particular machine (say, for example machineM3) is exclusively using an object or class (or any other asset orresource), another machine (say, for example machine M5) may also beinstructed by the code it is executing to exclusively use the localsimilar equivalent object or class corresponding to the similarequivalent object or class on machine M3 at the same time or anoverlapping time period. Thus if the same corresponding local similarequivalent objects or classes on each machine M3 and M5 were to beexclusively used by both machines, then the behaviour of the object andapplication as a whole is undefined—that is, in the absence of properexclusive use of an object (or class) when explicitly specified by thecomputer program (programmer), conflict, race conditions, unwantedinteractions, anomalous behaviour due to unexpected dependence on therelative timing of events, or permanent inconsistency between thesimilar equivalent objects on machines M5 and M3 is likely to result.Thus the desirable result of achieving or providing consistent,coordinated, and coherent operation of synchronization routines (orother mutual exclusion operations) between and amongst a plurality ofmachines, as required for the simultaneous and coordinated operation ofthe same application program code on each of the plurality of machinesM1, M2 . . . Mn, would not be achieved.

In order to ensure consistent synchronization between and amongstmachines M1, M2 . . . Mn the application code 50 is analysed orscrutinized by searching through the executable application code 50 inorder to detect program steps (such as particular instructions orinstruction types) in the application code 50 which define or constituteor otherwise represent a synchronization routine (or other mutualexclusion operation). In the JAVA language, such program steps may forexample comprise or consist of an opening monitor enter (e.g.“monitorenter”) instruction and one or more closing monitor exit (e.g.“monitorexit”) instructions. In one embodiment, a synchronizationroutine may start with the execution of a “monitorenter” instruction andclose with a paired execution of a “monitorexit” instruction.

This analysis or scrutiny of the application code 50 may take placeeither prior to loading the application program code 50, or during theapplication program code 50 loading procedure, or even after theapplication program code 50 loading procedure. It may be likened to aninstrumentation, program transformation, translation, or compilationprocedure in that the application code may be instrumented withadditional instructions, and/or otherwise modified by meaning-preservingprogram manipulations, and/or optionally translated from an input codelanguage to a different code language (such as for example fromsource-code language or intermediate-code language to object-codelanguage or machine-code language), and with the understanding that theterm compilation normally or conventionally involves a change in code orlanguage, for example, from source code to object code or from onelanguage to another language. However, in the present instance the term“compilation” (and its grammatical equivalents) is not so restricted andcan also include or embrace modifications within the same code orlanguage. For example, the compilation and its equivalents areunderstood to encompass both ordinary compilation (such as for exampleby way of illustration but not limitation, from source-code toobject-code), and compilation from source-code to source-code, as wellas compilation from object-code to object-code, and any alteredcombinations therein. It is also inclusive of so-called “intermediarylanguages” which are a form of “pseudo object-code”.

By way of illustration and not limitation, in one embodiment, theanalysis or scrutiny of the application code 50 may take place duringthe loading of the application program code such as by the operatingsystem reading the application code from the hard disk or other storagedevice or source and copying it into memory and preparing to beginexecution of the application program code. In another embodiment, in aJAVA virtual machine, the analysis or scrutiny may take place during theclass loading procedure of the java.lang.ClassLoader loadClass method(e.g., “java.lang.ClassLoader.loadClass( )”).

Alternatively, the analysis or scrutiny of the application code 50 maytake place even after the application program code loading procedure,such as after the operating system has loaded the application code intomemory, or optionally even after execution of the application programcode has started, such as for example after the JAVA virtual machine hasloaded the application code into the virtual machine via the“java.lang.ClassLoader.loadClass( )” method and optionally commencedexecution.

Reference is made to the accompanying Annexure D in which: Annexure D1is a typical code fragment from a synchronization routine prior tomodification (e.g., an exemplary unmodified synchronization routine),and Annexure D2 is the same synchronization routine after modification(e.g., an exemplary modified synchronization routine). These codefragments are exemplary only and identify one software code means forperforming the modification in an exemplary language. It will beappreciated that other software/firmware or computer program code may beused to accomplish the same or analogous function or operation withoutdeparting from the invention.

Annexures D1 and D2 (also reproduced in part in Tables XX and XXI below)are exemplary code listings that set forth the conventional orunmodified computer program software code (such as may be used in asingle machine or computer environment) of a synchronization routine ofapplication program 50 and a post-modification excerpt of the samesynchronization routine such as may be used in embodiments of thepresent invention having multiple machines. The modified code that isadded to the synchronization method is highlighted in bold text. Otherembodiments of the invention may provide for code or statements orinstructions to be added, amended, removed, moved or reorganized, orotherwise altered.

It is noted that the compiled code in the Annexure and portion repeatedin the table is taken from the source-code of the file “example.java”which is included in the Annexure D3. The disassembled compiled codethat is listed in the Annexure and Table is taken from compiled sourcecode of the file “EXAMPLE.JAVA”. In the procedure of Annexure D1 andTable XX, the procedure name “Method void run( )” of Step 001 is thename of the displayed disassembled output of the run method of thecompiled application code of “example.java”. The name “Method void run()” is arbitrary and selected for this example to indicate a typical JAVAmethod inclusive of a synchronization operation. Overall the method isresponsible for incrementing a memory location (“counter”) in athread-safe manner through the use of a synchronization statement andthe steps to accomplish this are described in turn.

First (Step 002), the Java Virtual Machine instruction “getstatic#2<Field java.lang.Object LOCK>” causes the Java Virtual Machine toretrieve the object reference of the static field indicated by theCONSTANT_Fieldref_info constant-pool item stored in the 2nd index of theclassfile structure of the application program containing this examplerun( ) method and results in a reference to the object (hereafterreferred to as LOCK) in the field to be placed (pushed) on the stack ofthe current method frame of the currently executing thread.

Next (Step 003), the Java Virtual Machine instruction “dup” causes theJava Virtual Machine to duplicate the topmost item of the stack and pushthe duplicated item onto the topmost position of the stack of thecurrent method frame and results in the reference to the LOCK object atthe top of the stack being duplicated and pushed onto the stack.

Next (Step 004), the Java Virtual Machine instruction “astore_(—)1”causes the Java Virtual Machine to remove the topmost item of the stackof the current method frame and store the item into the local variablearray at index 1 of the current method frame and results in the topmostLOCK object reference of the stack being stored in the local variableindex 1.

Then (Step 005), the Java Virtual Machine instruction “monitorenter”causes the Java Virtual Machine to pop the topmost object off the stackof the current method frame and acquire an exclusive lock on said poppedobject and results in a lock being acquired on the LOCK object.

The Java Virtual Machine instruction “getstatic #3<Field int counter>”(Step 006) causes the Java Virtual Machine to retrieve the integer valueof the static field indicated by the CONSTANT_Fieldref_infoconstant-pool item stored in the 3rd index of the classfile structure ofthe application program containing this example run( ) method andresults in the integer value of said field being placed (pushed) on thestack of the current method frame of the currently executing thread.

The Java Virtual Machine instruction “iconst_(—)1” (Step 007) causes theJava Virtual Machine to load an integer value of “1” onto the stack ofthe current method frame and results in the integer value of 1 loadedonto the top of the stack of the current method frame.

The Java Virtual Machine instruction “iadd” (Step 008) causes the JavaVirtual Machine to perform an integer addition of the two topmostinteger values of the stack of the current method frame and results inthe resulting integer value of the addition operation being placed onthe top of the stack of the current method frame.

The Java Virtual Machine instruction “putstatic #3<Field int counter>”(Step 009) causes the Java Virtual Machine to pop the topmost value offthe stack of the current method frame and store the value in the staticfield indicated by the CONSTANT_Fieldref_info constant-pool item storedin the 3^(rd) index of the classfile structure of the applicationprogram containing this example run( ) method and results in the topmostinteger value of the stack of the current method frame being stored inthe integer field named “counter”.

The Java Virtual Machine instruction “aload_(—)1” (Step 010) causes theJava Virtual Machine to load the item in the local variable array atindex 1 of the current method frame and store this item on the top ofthe stack of the current method frame and results in the objectreference stored in the local variable array at index 1 being pushedonto the stack.

The Java Virtual Machine instruction “monitorexit” (Step 011) causes theJava Virtual Machine to pop the topmost object off the stack of thecurrent method frame and release the exclusive lock on said poppedobject and results in the LOCK being released on the LOCK object.

Finally, the Java Virtual Machine instruction “return” (Step 012) causesthe Java Virtual Machine to cease executing this run( ) method byreturning control to the previous method frame and results intermination of execution of this run( ) method.

As a result of these steps operating on a single machine of theconventional configurations in FIG. 1 and FIG. 2, the synchronizationstatement enclosing the increment operation of the “counter” memorylocation ensures that no two or more concurrently execution instances ofthis run( ) method will conflict, or otherwise result in unwantedinteractions such as a race-condition or other anomalous behaviour dueto unexpected critical dependence on the relative timing of theincrementing events performed of the one “counter” memory location. Werethese steps to be carried out on the plurality of machines of theconfigurations of FIG. 5 and FIG. 8 with the memory update andpropagation replication means of FIGS. 9, 10, 11, 12 and 13, andconcurrently executing two or more instances or occurrences of the run() method each on a different one of the plurality of machines M1, M2 . .. Mn, the mutual exclusion operations of each concurrently executinginstance of the run( ) method would be performed on each correspondingone of the machines without coordination between those machines.

Given the desirable result of consistent coordinated synchronizationoperation across a plurality of machines, this prior art arrangementwould fail to perform such consistent coordinated synchronizationoperation across the plurality of machines, as each machine performssynchronization only locally and without any attempt to coordinate theirlocal synchronization operation with any other similar synchronizationoperation on any one or more other machines. Such an arrangement wouldtherefore be susceptible to conflict or other unwanted interactions(such as race-conditions or other anomalous behaviour due to unexpectedcritical dependence on the relative timing of the “counter” incrementevents on each machine) between the machines M1, M2, . . . , Mn.Therefore it is desirable to overcome this limitation of the prior artarrangement.

In the exemplary code in Table XXI (Annexure D2), the code has beenmodified so that it solves the problem of consistent coordinatedsynchronization operation for a plurality of machines M1, M2, . . . ,Mn, that was not solved in the code example from Table XX (Annexure D1).In this modified run( ) method code, a “dup” instruction is insertedbetween the “4 astore_(—)1” and “6 monitorenter” instructions. Thiscauses the Java Virtual Machine to duplicate the topmost item of thestack and push said duplicated item onto the topmost position of thestack of the current method frame and results in the reference to theLOCK object at the top of the stack being duplicated and pushed onto thestack.

Furthermore, the Java Virtual Machine instruction “invokestatic#23<Method void acquireLock(java.lang.Object)>” is inserted after the “6monitorenter” and before the “10 getstatic #3<Field int counter>”statements so that the Java Virtual Machine pops the topmost item offthe stack of the current method frame and invokes the “acquireLock”method, passing the popped item to the new method frame as its firstargument. This change is particularly significant because it modifiesthe run( ) method to execute the “acquireLock” method and associatedoperations, corresponding to the “monitorenter” instruction precedingit.

Annexure D1 is a before-modification excerpt of the disassembledcompiled form of the synchronization operation of example.java ofAnnexure D3, consisting of an starting “monitorenter” instruction andending “monitorexit” instruction. Annexure D2 is an after-modificationform of Annexure D1, modified by LockLoader.java of Annexure D6 inaccordance with the steps of FIG. 26. The modifications are highlightedin bold.

TABLE XX Annexure D1 Step Annexure D1 001 Method void run( ) 002  0getstatic #2 <Field java.lang.Object LOCK> 003  3 dup 004  4 astore_1005  5 monitorenter 006  6 getstatic #3 <Field int counter> 007  9iconst_1 008 10 iadd 009 11 putstatic #3 <Field int counter> 010 14aload_1 011 15 monitorexit 012 16 return

TABLE XXI Annexure D2 Step Annexure D2 001 Method void run( ) 002  0getstatic #2 <Field java.lang.Object LOCK> 003  3 dup 004  4 astore_1004A  5 dup 005  6 monitorenter 005A  7 invokestatic #23 <Method void   acquireLock(java.lang.Object)> 006   10 getstatic #3 <Field int counter>007   13 iconst_1 008   14 iadd 009   15 putstatic #3 <Field intcounter> 010   18 aload_1 010A   19 dup 010B   20 invokestatic #24<Method void    releaseLock(java.lang.Object)> 011   23 monitorexit   24return

The method void acquireLock(java.lang.Object), part of the LockClientcode of Annexure D4 and part of the distributed runtime system (DRT) 71,performs the communications operations between machines M1, . . . , Mnto coordinate the execution of the preceding “monitorenter”synchronization operation amongst the machines M1 . . . Mn. TheacquireLock method of this example communicates with the LockServer codeof Annexure D5 executing on a machine X of FIG. 15, by means of sendingan ‘acquire lock request’ to machine X corresponding to the object being‘locked’ (i.e., the object corresponding to the “monitorenter”instruction), which in the context of Table XXI and Annexure D2 is the‘LOCK’ object. With reference to FIG. 29, Machine X receives the‘acquire lock request’ corresponding to the LOCK object, and consults atable of locks to determine the lock status corresponding to theplurality of similar equivalent objects on each of the machines, whichin the case of Annexure D2 is the plurality of similar equivalent LOCKobjects.

If all of the plurality of similar equivalent objects on each of theplurality of machines M1 . . . Mn is presently not locked by any othermachine M1 . . . Mn, then Machine X will record the object as now lockedand inform the requesting machine of the successful acquisition of thelock. Alternatively, if a similar equivalent object is presently lockedby another one of the machines M1 . . . Mn, then Machine X will appendthis requesting machine to a queue of machines waiting to lock thisplurality of similar equivalent objects, until such a time as machine Xdetermines this requesting machine can acquire the lock. Correspondingto the successful acquisition of a lock by a requesting machine, a replyis generated and sent to the successful requesting machine informingthat machine of the successful acquisition of the lock. Following areceipt of such a message from Machine X confirming the successfulacquisition of a requested lock, the acquireLock method and operationsterminate execution and return control to the previous method frame,which is the context of Annexure D2 is the executing method frame of therun( ) method. Until such a time as the requesting machine receives areply from machine X confirming the successful acquisition of therequested lock, the operation of the acquireLock method and run( )method are suspended until such a confirmatory reply is received.Following this return operation, the execution of the run( ) method thenresumes. Exemplary source-code for an embodiment of the acquireLockmethod is provided in Annexure D4. Annexure D4 also provides additionaldetail concerning DRT 71 functionality.

Later, the two statements “dup” and “invokestatic #24 <Method voidreleaseLock(java.lang.Object)>” are inserted into the code stream afterthe “18 aload_(—)1” statement and before the “23 monitorexit” statement.These two statements cause the Java Virtual Machine to duplicate theitem on the stack and then invoke the releaseLock method with thetopmost item of the stack as an argument to the method call and resultin the modification of the run( ) method to execute the “releaseLock”method and associated operations, corresponding to the following“monitorexit” instruction, before the procedure exits and returns.

The method void releaseLock(java.lang.Object), part of the LockClientcode of Annexure D4 and part of the distributed runtime system (DRT) 71,performs the communications operations between machines M1 . . . Mn tocoordinate the execution of the following “monitorexit” synchronizationoperation amongst the machines M1 . . . Mn. The releaseLock method ofthis example communications with LockServer code of Annexure D5executing on a machine X of FIG. 15, by means of sending a “release lockrequest” to machine X corresponding to the object being “unlocked”(i.e., the object corresponding to the “monitorexit” instruction), whichin the context of Table XXI and Annexure D2 is the ‘LOCK’ object.Corresponding to FIG. 30, machine X receives the “release lock request”corresponding to the LOCK object, and updates the table of locks toindicate the lock status corresponding to the plurality of similarequivalent ‘LOCK’ objects as now “unlocked”. Additionally, if there areother machines awaiting acquisition of this lock, then machine X is ableto select one of the awaiting machines to be the new owner of the lockby updating the table of locks to indicate this selected one awaitingmachine as the new lock owner, and informing the successful one of theawaiting machines of its successful acquisition of the lock by means ofa confirmatory reply. The successful one of the awaiting machines thenresumes execution of its synchronization routine. Following thenotification to machine X of lock release, the releaseLock methodterminates execution and returns control to the previous method frame,which in this instance is the method frame of the run( ) method.Following this return operation, the execution of the run( ) methodresumes.

It will be appreciated that the modified code permits, in a distributedcomputing environment having a plurality of computers or computingmachines, the coordinated operation of synchronization routines or othermutual exclusion operations between and amongst machines M1 . . . Mn sothat the problems associated with the operation of the unmodified codeor procedure on a plurality of machines M1 . . . Mn (such as conflicts,unwanted interactions, race-conditions, or anomalous behaviour due tounexpected critical dependence on the relative time of events) does notoccur when applying the modified code or procedure.

In the unmodified code sample of Annexure D1, the application programcode includes instructions or operations that increment a memorylocation in local memory (used for a counter) within an enclosingsynchronization routine. The purpose of the synchronization routine isto ensure thread-safety of the counter memory increment operation inmulti-threaded and multi-processing applications and computer systems.The terms thread-safe or thread-safety refer to code that is eitherre-entrant or protected from multiple simultaneous execution by someform of mutual exclusion. Multi-threaded applications in the context ofthe invention may, for example, include applications operating two ormore threads of execution concurrently each on a different machine.Thus, without the management of coordinated synchronization inenvironments comprising or consisting of a plurality of machines, eachrunning concurrently executing part of a same application program, andwith a memory updating and propagation replication means of FIGS. 9, 10,11, 12, and 13, each computer or computing machine would performsynchronization in isolation, thus potentially incrementing the sharedcounter at the same time, leading to potential conflicts or unwantedinteractions such as race condition(s) and incoherent memory between themachines M1 . . . Mn. It will be appreciated that although thisembodiment is described using a shared counter, the use or provision ofsuch shared counter or memory location is optional and not required forthe synchronization aspects of the invention. What is advantageous isthat the synchronization routine behaves in a manner as the programminglanguage, runtime system, or machine architecture (or any combinationthereof) guarantees—that is, stop two parts (for example, two threads)of the application program from executing the same synchronizationroutine or same mutual exclusion operation or operator concurrently.Clearly consistent, coherent and coordinated synchronization behaviouris what the programmer or user of the application program code 50expects to happen.

So, taking advantage of the DRT 71, the application code 50 is modifiedas it is loaded into the machine by changing the synchronizationroutine. It will be appreciated in light of the description providedhere that the modifications made on each machine may generally besimilar in-so-far as they should advantageously achieve a consistent endresult of coordinated synchronization operation amongst all themachines; however, given the broad applicability of the inventivesynchronization method and associated procedures, the nature of themodifications may generally vary without altering the effect produced.For example, in a simple variation, one or more additional instructionsor statements may be inserted, such as for example a “no-operation”(nop) type instruction into the application will mean the modificationsmade are technically different, but the modified code still conforms tothe invention. Embodiments of the invention may for example, implementthe changes by means of program transformation, translation, variousforms of compilation, instrumentation, or by other means describedherein or known in the art. The changes made (highlighted in bold text)are the starting or initial instructions and the ending instructionsthat the synchronization routine executes, and which correspond to theentry (start) and exit (finish) of the synchronization routinerespectively. These added instructions (or modified instruction stream)act to coordinate the execution of the synchronization routine amongstthe multiple concurrently executing instances or occurrences of themodified run method executing on each one of, or some subset of, theplurality of machines M1 . . . Mn, by invoking the acquireLock methodcorresponding to the start of execution of the synchronization routine,and by invoking the releaseLock method corresponding to the finish ofexecution of the synchronization routine, thereby providing consistentcoordinated operation of the synchronization routine (or other mutualexclusion operation or operator) as required for the simultaneousoperation of the modified application program code that is running on oracross the plurality of machines M1, M2, . . . , Mn. This alsoadvantageously provides for operation of the one application program ina coordinated manner across the machines.

The acquire lock (e.g. “acquireLock( )”) method of the DRT 71 takes anargument “(java.lang.Object)” which represents a reference to (or someother unique identifier for) the particular local object for which theglobal lock is desired (See Annexure D2 and Table XXI), and is to beused in acquiring a global lock across the plurality of similarequivalent objects on the other machines corresponding to the specifiedlocal object. The unique identifier may, for example be the name of theobject, a reference to the object in question, or a unique numberrepresenting the plurality of similar equivalent objects across allnodes. By using a globally unique identifier across all connectedmachines to represent the plurality of similar equivalent objects on theplurality of machines, the DRT can support the synchronization ofmultiple objects at the same time without becoming confused as to whichof the multiple objects are already synchronized and which are not asmight be the case if object (or class) identifiers were not unique, byusing the unique identifier of each object to consult the correct recordin the shared synchronization table.

A further advantage of using a global identifier here is as a form of‘meta-name’ for all the similar equivalent local objects on each one ofthe machines. For example, rather than having to keep track of eachunique local name of each similar equivalent local object on eachmachine, one may instead define a global name (e.g., “globalname7787”)which each local machine in turn maps to a local object (e.g.,“globalname7787” points to object “localobject456” on machine M1, and“globalname7787” points to object “localobject885” on machine M2, and“globalname7787” points to object “localobject111” on machine M3, and soforth). It thereafter is easier to simply say “acquire lock forglobalname7787” which is then translated on machine 1 (M1) to mean“acquire lock for localobject456”, and is translated on machine 2 (M2)to mean “acquire lock for localobject885”, and so on.

The shared synchronization table that may optionally be used is a table,other storage means, or any other data structure that stores an object(and/or class or other asset) identifier and the synchronization status(or locked or unlocked status) of each object (and/or class or otherasset). The table or other storage means operates to relate an object(and/or class or other asset, or a plurality of similar equivalentobjects or classes or assets) to a status of either locked or unlockedor some other physical or logical indication of a locked state and anunlocked state. For example: the table (or any other data structure onecares to employ) may advantageously include a named object identifierand a record indicating if a named object (i.e., “globalname7787”) islocked or unlocked. In one embodiment, the table or other storage meansstores a flag or memory bit, wherein when the flag or memory bit storesa “0” the object is unlocked and when the flag or memory bit stores a“1” the object is locked. Clearly, multiple bit or byte storage may beused and different logic sense or indicators may be used withoutdeparting from the invention.

The DRT 71 can determine the synchronization state of the object in anyone of a number of ways. Recall, for example that the invention mayinclude any means of implementing thread-safety, regardless of whetherit is through the use of locks (lock/unlock), synchronizations,monitors, semphafores, mutexes, or other mechanisms. These means stop orlimit concurrently executing parts of a single application program inorder to guarantee consistency according to the rules ofsynchronization, locks, or the like. Preferably, it can ask each machinein turn if their local similar equivalent object (or class or otherasset or resource) corresponding to the object being sought to be lockedis presently synchronized, and if any machine replies true, then topause execution of the synchronization routine and wait until thatpresently synchronized similar equivalent object on the other machine isunsynchronised, otherwise synchronize this object locally and resumeexecution of the synchronization routine. Each machine may implementsynchronization (or mutual exclusion operations or operators) in its ownway and this may be different in the different machines. Therefore,although some exemplary implementation details are provided, ultimatelyhow synchronization (or mutual exclusion operations) is (are)implemented, or precisely how synchronization or mutual exclusion status(or locked/unlocked status) is recorded in memory or other storagemeans, is not critical to the invention. By unsynchronized we generallymean unlocked or otherwise not subject to a mutual exclusion operation,and by synchronized we generally mean locked and subject to a mutualexclusion operation.

Alternatively, the DRT 71 on each local machine can consult a sharedrecord table (perhaps on a separate machine (for example, on machine Xwhich is different from machines M1, M2, . . . , Mn)), or can consult acoherent shared record table on each one of the local machines, or ashared database established in a memory or other storage, to determineif this object has been marked or identified as synchronized (or“locked”) by any machine and if so, then wait until the status of theobject is changed to “unlocked” and then acquire the lock on thismachine, otherwise acquire the lock by marking the object as locked(optionally by this machine) in the shared lock table.

In the situation where the shared record table is consulted, this may beconsidered as a variation of a shared database or data structure, whereeach machine has a local copy of a shared table (that is a replica of ashared table) with is updated to maintain coherency across the pluralityof machines M1, . . . , Mn.

In one embodiment, the shared record table refers to a shared tableaccessible by all machines M1, . . . , Mn, that may for example bedefined or stored in a commonly accessibly database such that anymachine M1, . . . , Mn can consult or read this shared database tablefor the locked or unlocked status of an object. A further alternativearrangement is to implement a shared record table as a table in thememory of an additional machine (which we call “machine X”) which storeseach object identification name and its lock status, and serves as thecentral repository which all other machines M1, . . . , Mn consult todetermine locked status of similar equivalent objects.

In any of these different alternative implementations, the manner inwhich a one of, or a plurality of, similar equivalent objects is markedor identified as being synchronized (or locked) or unsynchronized (orunlocked) is relatively unimportant, and various stored memory bits orbytes or flags may be utilized as are known in the art to identifyeither one of the two possible logic states. It will also be appreciatedthat in the present embodiment, that synchronized is largely synonymouswith locked and unsynchronized is largely synonymous with unlocked.These same considerations apply for classes as well as for other assetsor resources.

Recall that the DRT 71 is responsible for determining the locked statusfor an object (or class, or other asset, corresponding to a plurality ofsimilar equivalent objects or classes or assets) seeking to be lockedbefore allowing the synchronization routine corresponding to theacquisition of that lock to proceed. In the exemplary embodimentdescribed here, the DRT consults the shared synchronization record tablewhich in one embodiment resides on an special “machine X”, and thereforethe DRT needs to communicate via the network or other communicationslink or path with this machine X to enquire as to and determine thelocked (or unlocked) status of the object (or class or other assetcorresponding to a plurality of similar equivalent objects or classes orassets).

If the DRT on the local machine that is trying to execute asynchronization routine or other mutual exclusion operation determinesthat no other machine currently has a lock for this object (i.e., noother machine has synchronized this object) or any other one of aplurality of similar equivalent objects, then to acquire the lock forthis object corresponding to the plurality of similar equivalent objectson all other machines, for example by means of modifying thecorresponding entry in a shared table of locked states for the objectsought to be locked or alternatively, sequentially acquiring the lock onall other similar equivalent objects on all other machines in additionto the current machine. Note that the intent of this procedure is tolock the plurality of similar equivalent objects (or classes or assets)on all the other machines M1, . . . , Mn so that simultaneous orconcurrent use of any similar equivalent objects by two or more machinesis prevented, and any available approach may be utilized to accomplishthis coordinated locking. For example, it does not matter if machine M1instructs M2 to lock its similar equivalent local object, then instructsM3 to lock its similar equivalent local object, and then instructs M4and so on; or if M1 instructs M2 to lock its similar equivalent localobject, and then M2 instructs M3 to lock its similar equivalent localobject, and then M3 instructs M4 to lock its similar equivalent localobject, and so forth, what is being sought is the locking of the similarequivalent objects on all other machines so that simultaneous orconcurrent use any similar equivalent objects by two or more machines isprevented. Only once this machine has successfully confirmed that noother machine has currently locked a similar equivalent object, and thismachine has correspondingly locked its locally similar equivalentobject, can the execution of the synchronization routine or code-blockbegin.

On the other hand, if the DRT 71 within the machine about to execute asynchronization routine (such as machine M1) determines that anothermachine, such as machine M4 has already synchronized a similarequivalent object, then this machine M1 is to postpone continuedexecution of the synchronization routine (or code-block) until such atime as the DRT on machine M1 can confirm than no other machine (such asone of machines M2, M3, M4, or M5, . . . , Mn) is presently executing asynchronize routine on a corresponding similar equivalent local object,and that this machine M1 has correspondingly synchronized its similarequivalent object locally. Recall that local synchronization refers toprior art conventional synchronization on a single machine, whereasglobal or coordinated synchronization refers to coordinatedsynchronization of, across and/or between similar equivalent localobjects each on a one of the plurality of machines M1. Mn. In such acase, the synchronization routine (or code-block) is not to continueexecution until this machine M1 can guarantee that no other machine M2,M3, M4, . . . , Mn is executing a synchronization routine correspondingto the local similar equivalent object being sought to be locked, as itwill potentially corrupt the object across the participating machinesM1, M2, M3, . . . , Mn due to susceptibility to conflicts or otherunwanted interactions such as race-conditions, and the like problemsresulting from the concurrent execution of synchronization routines.Thus, when the DRT determines that this object, or a similar equivalentobject on another machine, is presently “locked”, say by machine M4(relative to all other machines), the DRT on machine M1 pauses executionof the synchronization routine by pausing the execution of the acquirelock (e.g., “acquireLock( )”) operation until such a time as acorresponding release lock (e.g., “releaseLock( )”) operation isexecuted by the present owner of the lock (e.g., machine M4).

Thus, on execution of a release lock (e.g. “releaseLock( )”) operation,the machine M4 which presently “owns” or holds a lock (i.e., isexecuting a synchronization routine) indicates the close of itssynchronization routine, for example by marking this object as“unlocked” in the shared table of locked states, or alternatively,sequentially releasing locks acquired on all other machines. At thispoint, a different machine waiting to begin execution of a pausedsynchronization statement can then claim ownership of this now releasedlock by resuming execution of its postponed (i.e. delayed) “acquireLock()” operation, for example, by marking itself as executing a lock forthis similar equivalent object in the shared table of synchronizationstates, or alternatively, sequentially acquiring local locks of similarequivalent objects on each of the other machines. It is to be understoodthat the resumed execution of the acquire lock (e.g., “acquireLock”)operation is to be inclusive of the optional resumption of execution ofthe acquire lock (e.g., “acquireLock”) method at the point thatexecution was paused, as well as the alternative optional arrangementwherein the execution of the acquire lock (e.g., “acquireLock”)operation is repeated so as to re-request the lock. Again, these sameconsiderations also apply for classes and more generally to any asset orresource.

So, according to at least one embodiment and taking advantage of theoperation of the DRT 71, the application code 50 is modified as it isloaded into the machine by changing the synchronization routine(consisting of at least a beginning “acquire lock” type instruction(such as a JAVA “monitorenter” instruction) and an ending “release lock”type instruction (such as a JAVA “monitorexit” instruction). “Acquirelock” type instructions commence operation or execution of a mutualexclusion operation, generally corresponding to a particular asset suchas a particular memory location or machine resource, and result in theasset corresponding to the mutual exclusion operation being locked withrespect to some or all modes of simultaneous or concurrent use,execution or operation. “Release lock” type instructions terminate orotherwise discontinue operation or execution of a mutual exclusionoperation, generally corresponding to a particular asset such as aparticular memory location or machine resource, and result in the assetcorresponding to the mutual exclusion operation being unlocked withrespect to some or all modes of simultaneous or concurrent use,execution or operation. The changes made (highlighted in bold) are themodified instructions that the synchronization routine executes. Theseadded instructions for example check if this lock has already beenacquired by another machine. If this lock has not been acquired byanother machine, then the DRT of this machine notifies all othermachines that this machine has acquired the specified lock, and therebystopping the other machines from executing synchronization routinescorresponding to this lock.

The DRT 71 can determine and record the lock status of similarequivalent objects, or other corresponding memory location or machine orsoftware resource on a plurality of machines, in many ways, such as forexample, by way of illustration but not limitation:

1. Corresponding to the entry to a synchronization routine by MachineM1, the DRT of machine M1 individually consults or communicates witheach machine to ascertain if this global lock is already acquired by anyother Machine M2, . . . , Mn different from itself. If this global lockcorresponding to this asset or object is or has already been acquired byanother one of the machines M2, . . . , Mn then the DRT of Machine M1pauses execution of the synchronization routine on machine M1 until allother machines no longer own a global lock on this asset or object (thatis to say that none of the other machines any longer own a global lockcorresponding to this asset or object), at which point machine M1 cansuccessfully acquire the global lock such that all other machines M2, .. . , Mn must now wait for machine M1 to release the global lock beforea different machine can in turn acquire it. Otherwise, when it isdetermined that this global lock corresponding to this asset or objecthas not already been acquired by another machine M2, . . . , Mn the DRTcontinues execution of the synchronization routine, and such that allother machines M2, . . . , Mn must now wait for machine M1 to releasethe global lock before a different machine can in turn acquire it.

Alternatively, 2. Corresponding to the entry to a synchronizationroutine, the DRT consults a shared table of records (for example ashared database, or a copy of a shared table on each of theparticipating machines) which indicate if any machine currently “owns”this global lock. If so, the DRT then pauses execution of thesynchronization routine on this machine until no machine owns a globallock on a similar equivalent object. Otherwise the DRT records thismachine in the shared table (or tables, if there are multiple tables ofrecords, e.g., on multiple machines) as the owner of this global lock,and then continues executing the synchronization routine.

Similarly, when a global lock is released, that is to say, when theexecution of a synchronization routine is to end, the DRT can“un-record”, alter the status indicator, and/or reset the global lockstatus of machines in many alternative ways, for example by way ofillustration but not limitation:

1. Corresponding to the exit to a synchronization routine, the DRTindividually notifies each other machine that it no longer owns theglobal lock.

Alternatively,

2. Corresponding to the exit to a synchronization routine, the DRTupdates the record for this globally locked asset or object (such as forexample a plurality of similar equivalent objects or assets) in theshared table(s) of records such that this machine is no longer recordedas owning this global lock.

Still further, the DRT can provide an acquire global lock queue to queuemachines needing to acquire a global lock in multiple alternative ways,for example by way of illustration but not limitation:

1. Corresponding to the entry to a synchronization routine by Machine M1say, the DRT of machine M1 notifies the present owning machine (sayMachine M4) of the global lock that machine M1 would like to or needs toacquire the corresponding global lock upon release by the current owningmachine in order to perform an operation. The specified machine M4, ifthere are no other waiting machines, then stores a record of therequesting machine's (i.e., machine M1) interest or request in a tableor list, such that machine M4 may know subsequent to releasing thecorresponding global lock that the machine M1 recorded in the table orlist is waiting to acquire the same global lock, which, following theexit of the synchronization routine corresponding to the global lockheld by machine M4, then notifies the waiting machine (i.e. machine M1)specified in the record of waiting machines, that the global lock can beacquired, and thus machine M1 can proceed to acquire the global lock andcontinue executing its own synchronization routine.

2. Corresponding to the entry to a synchronization routine by machine M1say, the DRT notifies the present owner of the global lock, say machineM4, that a specific machine (say machine M1) would like to acquire thelock upon release by that machine (i.e., machine M4). That machine M4,if it finds after consulting its records of waiting machines for thislocked object, finds that there are already one or more other machines(say machines M2 and M7) waiting, then either appends machine M1 to theend of the list of machines M2 and M7 wanting to acquire this lockedobject, or alternatively, forwards the request from M1 to the firstwaiting machine (i.e., machine M2), or any other machine waiting (i.e.,machine M7), which then, in turn, records machine M1 in their table orrecords of waiting machines.

In the example above, for example, the records may be kept on Machine M4and store a queue or other ordered or indexed list of machines waitingto acquire the lock after Machine M4 releases the lock it holds. Thislist or queue may then be used or referenced by M4 so that M4 can passthe lock on to other machines in accordance with the order of request orany other prioritization scheme. Alternatively, the list may beunordered, and machine M4 may pass the global lock on to any machine inthe list or record.

3. Corresponding to the entry to a synchronization routine, the DRTrecords itself in a shared table(s) of records (for example, a tablestored in a shared database accessible by all machines, or multipleseparate tables which are substantially similar).

Still further or in the alternative, the DRT 71 can notify othermachines queued to acquire this global lock corresponding to the exit ofa synchronization routine by this machine in the following alternativeways, for example:

1. Corresponding to the exit of a synchronization routine, the DRTnotifies one of the awaiting machines (for example, this first machinein the queue of waiting machines) that the global lock is released,

2. Corresponding to the exit of a synchronization routine, the DRTnotifies one of the awaiting machines (for example, the first machine inthe queue of waiting machines) that the global lock is released, andadditionally, provides a copy of the entire queue of machines (forexample, the second machine and subsequent machines awaiting for thisglobal lock). This way, the second machine inherits the list of waitingmachines from the first machine, and thereby ensures the continuity ofthe queue of waiting machines as each machine in turn down the listacquires and subsequently releases the same global lock.

During the abovementioned scrutiny, “monitorenter” and “monitorexit”instructions (or methods) are initially looked for and, when found, amodifying code is inserted so as to give rise to a modifiedsynchronization routine. This modified routine additionally acquires andreleases the global lock. There are several different modes whereby thismodification and loading can be carried out.

As seen in FIG. 15 a modification to the general arrangement of FIG. 8is provided in that machines M1, M2 . . . Mn are as before and run thesame application code 50 (or codes) on all machines M1 . . . Mnsimultaneously or concurrently. However, the previous arrangement ismodified by the provision of a server machine X which is convenientlyable to supply housekeeping functions, for example, and especially thesynchronization of structures, assets, and resources. Such a servermachine X can be a low value commodity computer such as a PC since itscomputational load is low. As indicated by broken lines in FIG. 15, twoserver machines X and X+1 can be provided for redundancy purposes toincrease the overall reliability of the system. Where two such servermachines X and X+1 are provided, they are preferably but optionallyoperated as redundant machines in a failover arrangement.

It is not necessary to provide a server machine X as its computationalload can be distributed over machines M1, M2 . . . Mn. Alternatively, adatabase operated by one machine (in a master/slave type operation) canbe used for the housekeeping function(s).

FIG. 16 shows a preferred general procedure to be followed. Afterloading 161 has been commenced, the instructions to be executed areconsidered in sequence and all synchronization routines are detected asindicated in step 162. In the JAVA language these are the “monitorenter”and “monitorexit” instructions, and methods marked as synchronized inthe method descriptor. Other languages use different terms.

Where a synchronization routine is detected 162, it is modified in step163 in order to perform consistent, coordinated, and coherentsynchronization operation (or other mutual exclusion operation) acrossthe plurality of machines M1 . . . Mn, typically by inserting furtherinstructions into the synchronization (or other mutual exclusion)routine to, for example, coordinate the operation of the synchronizationroutine amongst and between similar equivalent synchronization or othermutual exclusion operations on other one or more of the plurality ofmachines M1 . . . Mn, so that no two or more machines execute a similarequivalent synchronization or other mutual exclusion operation at onceor overlapping. Alternatively, the modifying instructions may beinserted prior to the routine, such as for example prior to theinstruction(s) or operation(s) related to a synchronization routine.Once the modification step 163 has been completed the loading procedurecontinues by loading the modified application code in place of theunmodified application code, as indicated in step 164. The modificationspreferably take the form of an “acquire lock on all other machines”operation and a “release lock on all other machines” modification asindicated at step 163.

FIG. 27 illustrates a particular form of modification. Firstly, thestructures, assets or resources (in JAVA termed classes or objects eg50A, 50X-50Y) or more generally “locks” to be synchronized have alreadybeen allocated a name or tag (for example a global name or tag) whichcan be used to identify corresponding similar equivalent local objects,or assets, or resources, or locks on each of the machines M1 . . . Mn,as indicated by step 172. This preferably happens when the classes orobjects are originally initialized. This is most conveniently done via atable maintained by server machine X. This table also includes thesynchronization status of the class or object or lock. It will beunderstood that this table or other data structure may store only thesynchronization status, or it may store other status or information aswell. In the preferred embodiment, this table also includes a queuearrangement which stores the identities of machines which have requesteduse of this asset or lock.

As indicated in step 173 of FIG. 27, next an “acquire lock” request issent to machine X, after which, the sending machine awaits forconfirmation of lock acquisition as shown in step 174. Thus, if theglobal name is already locked (i.e. a corresponding similar local assetis in exclusive use by another machine other than the machine proposingto acquire the lock) then this means that the proposed synchronizationroutine of the corresponding object or class or asset or lock should bepaused until the corresponding object or class or asset or lock isunlocked by the current owner.

Alternatively, if the global name is not locked, this means that noother machine is exclusively using a similar equivalent class, object,asset or lock, and confirmation of lock acquisition is received straightaway. After receipt of confirmation of lock acquisition, execution ofthe synchronization routine is allowed to continue, as shown in step175.

FIG. 28 shows the procedures followed by the application programexecuting machine which wishes to relinquish a lock. The initial step isindicated at step 181. The operation of this proposing machine istemporarily interrupted by steps 183, 184 until the reply is receivedfrom machine X, corresponding to step 184, and execution then resumes asindicated in step 185. Optionally, and as indicated in step 182, themachine requesting release of a lock is made to lookup the “global name”for this lock preceding a request being made to machine X. This way,multiple locks on multiple machines may be acquired and released withoutinterfering with one another.

FIG. 29 shows the activity carried out by machine X in response to an“acquire lock” enquiry (of FIG. 27). After receiving an “acquire lock”request at step 191, the lock status is determined at steps 192 and 193and, if no—the named resource is not free or otherwise “locked”, theidentity of the enquiring machine is added at step 194 to (or forms) thequeue of awaiting acquisition requests. Alternatively, if the answer isyes—the named resource is free and “unlocked”—the corresponding reply issent at step 197. The waiting enquiring machine is then able to executethe synchronization routine accordingly by carrying out step 175 of FIG.27. In addition to the yes response, the shared table is updated at step196 so that the status of the globally named asset is changed to“locked”.

FIG. 30 shows the activity carried out by machine X in response to a“release lock” request of FIG. 28. After receiving a “release lock”request at step 201, machine X optionally, and preferably, confirms thatthe machine requesting to release the global lock is indeed the currentowner of the lock, as indicated in step 202. Next, the queue status isdetermined at step 203 and, if no-one is waiting to acquire this lock,machine X marks this lock as “unowned” (or “unlocked”) in the sharedtable, as shown in step 207, and optionally sends a confirmation ofrelease back to the requesting machine, as indicated by step 208. Thisenables the requesting machine to execute step 185 of FIG. 28.

Alternatively, if yes—that is, other machines are waiting to acquirethis lock—machine X marks this lock as now acquired by the next machinein the queue, as shown in step 204, and then sends a confirmation oflock acquisition to the queued machine at step 205, and consequentlyremoves the new lock owner from the queue of waiting machines, asindicated in step 206.

Given the fundamental concept of modifying the synchronization routines(or other mutual exclusion operations or operators) to coordinateoperation between and amongst a plurality of machines M1 . . . Mn, thereare several different ways or embodiments in which this coordinated,coherent and consistent synchronization (or other mutual exclusion)operation concept, method, and procedure may be carried out orimplemented.

In the first embodiment, a particular machine, say machine M2, loads theasset (for example a class or object) inclusive of a synchronizationroutine(s), modifies it, and then loads each of the other machines M1,M3 . . . Mn (either sequentially, or simultaneously or according to anyother order, routine, or procedure) with the modified asset (or class orobject) inclusive of the new modified synchronization routine(s). Notethat there may be one or a plurality of routine(s) corresponding to onlyone object in the application code, or there may be a plurality ofroutines corresponding to a plurality of objects in the applicationcode. Note that in one embodiment, the synchronization routine(s) thatis (are) loaded is binary executable object code. Alternatively, thesynchronization routine(s) that is (are) loaded is executableintermediate code.

In this arrangement, which may be termed “master/slave” each of theslave (or secondary) machines M1, M3, . . . , Mn loads the modifiedobject (or class), and inclusive of the new modified synchronizationroutine(s), that was sent to it over the computer communications networkor other communications link or path by the master (or primary) machine,such as machine M2, or some other machine such as a machine X of FIG.15. In a slight variation of this “master/slave” or “primary/secondary”arrangement, the computer communications network can be replaced by ashared storage device such as a shared file system, or a shareddocument/file repository such as a shared database.

Note that the modification performed on each machine or computer neednot and frequently will not be the same or identical. What is requiredis that they are modified in a similar enough way that in accordancewith the inventive principles described herein, each of the plurality ofmachines behaves consistently and coherently relative to the othermachines to accomplish the operations and objectives described herein.Furthermore, it will be appreciated in light of the description providedherein that there are a myriad of ways to implement the modificationsthat may for example depend on the particular hardware, architecture,operating system, application program code, or the like or differentfactors. It will also be appreciated that embodiments of the inventionmay be implemented within an operating system, outside of or without thebenefit of any operating system, inside the virtual machine, in anEPROM, in software, in firmware, or in any combination of these.

In a further variation of this “master/slave” or “primary/secondary”arrangement, machine M2 loads asset (such as class or object) inclusiveof an (or even one or more) synchronization routine in unmodified formon machine M2, and then (for example, machine M2 or each local machine)modifies the class (or object or asset) by deleting the synchronizationroutine in whole or part from the asset (or class or object) and loadsby means of a computer communications network or other communicationslink or path the modified code for the asset with the now modified ordeleted synchronization routine on the other machines. Thus in thisinstance the modification is not a transformation, instrumentation,translation or compilation of the asset synchronization routine but adeletion of the synchronization routine on all machines except one.

The process of deleting the synchronization routine in its entirety caneither be performed by the “master” machine (such as machine M2 or someother machine such as machine X of FIG. 15) or alternatively by eachother machine M1, M3, . . . , Mn upon receipt of the unmodified asset.An additional variation of this “master/slave” or “primary/secondary”arrangement is to use a shared storage device such as a shared filesystem, or a shared document/file repository such as a shared databaseas means of exchanging the code (including for example, the modifiedcode) for the asset, class or object between machines M1, M2, . . . , Mnand optionally a machine X of FIG. 15.

In a still further embodiment, each machine M1, . . . , Mn receives theunmodified asset (such as class or object) inclusive of one or moresynchronization routines, but modifies the routines and then loads theasset (such as class or object) consisting of the now modified routines.Although one machine, such as the master or primary machine maycustomize or perform a different modification to the synchronizationroutine sent to each machine, this embodiment more readily enables themodification carried out by each machine to be slightly different and tobe enhanced, customized, and/or optimized based upon its particularmachine architecture, hardware, processor, memory, configuration,operating system, or other factors, yet still similar, coherent andconsistent with other machines with all other similar modifications andcharacteristics that may not need to be similar or identical.

In a further arrangement, a particular machine, say M1, loads theunmodified asset (such as class or object) inclusive of one or moresynchronization routines and all other machines M2, M3, . . . , Mnperform a modification to delete the synchronization routine(s) of theasset (such as class or object) and load the modified version.

In all of the described instances or embodiments, the supply or thecommunication of the asset code (such as class code or object code) tothe machines M1, . . . , Mn, and optionally inclusive of a machine X ofFIG. 15, can be branched, distributed or communicated among and betweenthe different machines in any combination or permutation; such as byproviding direct machine to machine communication (for example, M2supplies each of M1, M3, M4, etc. directly), or by providing or usingcascaded or sequential communication (for example, M2 supplies M1 whichthen supplies M3 which then supplies M4, and so on), or a combination ofthe direct and cascaded and/or sequential.

In a still further arrangement, the machines M1 to Mn, may send some orall load requests to an additional machine X (see for example theembodiment of FIG. 15), which performs the modification to theapplication code 50 inclusive of an (and possibly a plurality of)synchronization routine(s) via any of the afore mentioned methods, andreturns the modified application code inclusive of the now modifiedsynchronization routine(s) to each of the machines M1 to Mn, and thesemachines in turn load the modified application code inclusive of themodified routines locally. In this arrangement, machines M1 to Mnforward all load requests to machine X, which returns a modifiedapplication program code 50 inclusive of modified synchronizationroutine(s) to each machine. The modifications performed by machine X caninclude any of the modifications covered under the scope of the presentinvention. This arrangement may of course be applied to some of themachines and other arrangements described herein before applied to otherof the machines.

Persons skilled in the computing arts will be aware of various possibletechniques that may be used in the modification of computer code,including but not limited to instrumentation, program transformation,translation, or compilation means.

One such technique is to make the modification(s) to the applicationcode, without a preceding or consequential change of the language of theapplication code. Another such technique is to convert the original code(for example, JAVA language source-code) into an intermediaterepresentation (or intermediate-code language, or pseudo code), such asJAVA byte code. Once this conversion takes place the modification ismade to the byte code and then the conversion may be reversed. Thisgives the desired result of modified JAVA code.

A further possible technique is to convert the application program tomachine code, either directly from source-code or via the abovementionedintermediate language or through some other intermediate means. Then themachine code is modified before being loaded and executed. A stillfurther such technique is to convert the original code to anintermediate representation, which is thus modified and subsequentlyconverted into machine code.

The present invention encompasses all such modification routes and alsoa combination of two, three or even more, of such routes.

Embodiment Including Memory Management and Replication ObjectInitialization, Finalization, and Synchronization

Having now described structures, procedures, computer program code andtools, and other aspects and features of a multiple computer system andcomputing method utilizing at least one of memory management andreplication object initialization, finalization, and synchronization itmay readily be appreciated that these may also optionally butadvantageously be applied in any combination.

It may also be appreciated that the memory management, initialization,finalization, and/or synchronization aspects of the invention may beimplemented or applied serially or sequentially or in parallel. Forexample, where the code is being scrutinized or analysed to identify ordetect particular code sections relevant to initialization, that sameanalysis or scrutinization may also attempt to identify or detect codesections relevant to finalization (or synchronization for example).Alternatively, separate sequential (or possibly overlapping) analysisand scrutiny may be utilized to separately detect code relevant toinitialization and finalization and synchronization. Any requiredmodification to the code may also be performed in combination orseparately, and furthermore, portions may be performed together whileother portions are performed separately.

Having now described aspects of the memory management and replication,initialization, finalization, and synchronization, attention is nowdirected to an exemplary operational scenario illustrating the manner inwhich application programs on two computers may simultaneously executethe same application program in a consistent, coherent manner.

In this regard, attention is directed to FIGS. 31-33, two laptopcomputers 101 and 102 are illustrated. The computers 101 and 102 are notnecessarily identical and indeed, one can be an IBM or IBM-clone and theother can be an APPLE computer. The computers 101 and 102 have twoscreens 105, 115 two keyboards 106, 116 but a single mouse 107. The twomachines 101, 102 are interconnected by a means of a single coaxialcable or twisted pair cable 314.

Two simple application programs are downloaded onto each of the machines101, 102, the programs being modified as they are being loaded asdescribed above. In this embodiment the first application is a simplecalculator program and results in the image of a calculator 108 beingdisplayed on the screen 105. The second program is a graphics programwhich displays four coloured blocks 109 which are of different coloursand which move about at random within a rectangular box 310. Again,after loading, the box 310 is displayed on the screen 105. Eachapplication operates independently so that the blocks 109 are in randommotion on the screen 105 whilst numerals within the calculator 108 canbe selected (with the mouse 107) together with a mathematical operator(such as addition or multiplication) so that the calculator 108 displaysthe result.

The mouse 107 can be used to “grab” the box 310 and move same to theright across the screen 105 and onto the screen 115 so as to arrive atthe situation illustrated in FIG. 32. In this arrangement, thecalculator application is being conducted on machine 101 whilst thegraphics application resulting in display of box 310 is being conductedon machine 102.

However, as illustrated in FIG. 33, it is possible by means of the mouse107 to drag the calculator 108 to the right as seen in FIG. 32 so as tohave a part of the calculator 108 displayed by each of the screens 105,115. Similarly, the box 310 can be dragged by means of the mouse 107 tothe left as seen in FIG. 32 so that the box 310 is partially displayedby each of the screens 105, 115 as indicated FIG. 33. In thisconfiguration, part of the calculator operation is being performed onmachine 101 and part on machine 102 whilst part of the graphicsapplication is being carried out the machine 101 and the remainder iscarried out on machine 102.

The foregoing describes only some embodiments of the present inventionand modifications, obvious to those skilled in the art, can be madethereto without departing from the scope of the present invention. Forexample, reference to JAVA includes both the JAVA language and also JAVAplatform and architecture.

In all described instances of modification, where the application code50 is modified before, or during loading, or even after loading butbefore execution of the unmodified application code has commenced, it isto be understood that the modified application code is loaded in placeof, and executed in place of, the unmodified application codesubsequently to the modifications being performed.

Alternatively, in the instances where modification takes place afterloading and after execution of the unmodified application code hascommenced, it is to be understood that the unmodified application codemay either be replaced with the modified application code in whole,corresponding to the modifications being performed, or alternatively,the unmodified application code may be replaced in part or incrementallyas the modifications are performed incrementally on the executingunmodified application code. Regardless of which such modificationroutes are used, the modifications subsequent to being performed executein place of the unmodified application code.

It is advantageous to use a global identifier is as a form of‘meta-name’ or ‘meta-identity’ for all the similar equivalent localobjects (or classes, or assets or resources or the like) on each one ofthe plurality of machines M1, M2 . . . Mn. For example, rather thanhaving to keep track of each unique local name or identity of eachsimilar equivalent local object on each machine of the plurality ofsimilar equivalent objects, one may instead define or use a global namecorresponding to the plurality of similar equivalent objects on eachmachine (eg “globalname7787”), and with the understanding that eachmachine relates the global name to a specific local name or object (eg“globalname7787” corresponds to object “localobject456” on machine M1,and “globalname7787” corresponds to object “localobject885” on machineM2, and “globalname7787” corresponds to object “localobject111” onmachine M3, and so forth).

It will also be apparent to those skilled in the art in light of thedetailed description provided herein that in a table or list or otherdata structure created by each DRT 71 when initially recording orcreating the list of all, or some subset of all objects (eg memorylocations or fields), for each such recorded object on each machine M1,M2 . . . Mn there is a name or identity which is common or similar oneach of the machines M1, M2 . . . Mn. However, in the individualmachines the local object corresponding to a given name or identity willor may vary over time since each machine may, and generally will, storememory values or contents at different memory locations according to itsown internal processes. Thus the table, or list, or other data structurein each of the DRTs will have, in general, different local memorylocations corresponding to a single memory name or identity, but eachglobal “memory name” or identity will have the same “memory value orcontent” stored in the different local memory locations. So for eachglobal name there will be a family of corresponding independent localmemory location with one family member in each of the computers.Although the local memory name may differ, the asset, object, locationetc has essentially the same content or value. So the family iscoherent.

It will also be apparent to those skilled in the art in light of thedescription provided herein that the abovementioned modification of theapplication program code 50 during loading can be accomplished in manyways or by a variety of means. These ways or means include, but are notlimited to at least the following five ways and variations orcombinations of these five, including by:

-   -   (i) re-compilation at loading,    -   (ii) a pre-compilation procedure prior to loading,    -   (iii) compilation prior to loading,    -   (iv) a “just-in-time” compilations, or    -   (v) re-compilation after loading (but, for example, before        execution of the relevant or corresponding application code in a        distributed environment).

Traditionally the term “compilation” implies a change in code orlanguage, for example, from source to object code or one language toanother. Clearly the use of the term “compilation” (and its grammaticalequivalents) in the present specification is not so restricted and canalso include or embrace modifications within the same code or language.

Given the fundamental concept of modifying memory manipulationoperations to coordinate operation between and amongst a plurality ofmachines M1, M2 . . . Mn, there are several different ways orembodiments in which this coordinated, coherent and consistent memorystate and manipulation operation concept, method, and procedure may becarried out or implemented.

In the first embodiment, a particular machine, say machine M2, loads theasset (such as class or object) inclusive of memory manipulationoperation(s), modifies it, and then loads each of the other machines M1,M3 . . . Mn (either sequentially or simultaneously or according to anyother order, routine or procedure) with the modified object (or class orother assert or resource) inclusive of the new modified memorymanipulation operation. Note that there may be one or a plurality ofmemory manipulation operations corresponding to only one object in theapplication code, or there may be a plurality of memory manipulationoperations corresponding to a plurality of objects in the applicationcode. Note that in one embodiment, the memory manipulation operation(s)that is (are) loaded is executable intermediary code.

In this arrangement, which may be termed “master/slave” each of theslave (or secondary) machines M1, M3 . . . Mn loads the modified object(or class), and inclusive of the new modified memory manipulationoperation(s), that was sent to it over the computer communicationsnetwork or other communications link or path be the master (or primary)machine, such as machine M2, or some other machine as a machine X. In aslight variation of this “master/slave” or “primary/secondary”arrangement, the computer communications network can be replaced by ashared storage device such as a shared file system, or a shareddocument/file repository such as a shared database.

Note that the modification performed on each machine or computer neednot and frequently will not be the same or identical. What is requiredis that they are modified in a similar enough way that each of theplurality of machines behaves consistently and coherently relative tothe other machines. Furthermore, it will be appreciated that there are amyriad of ways to implement the modifications that may for exampledepend on the particular hardware, architecture, operating system,application program code, or the like or different factors. It will alsobe appreciated that implementation can be within an operating system,outside of or without the benefit of any operating system, inside thevirtual machine, in an EPROM, in software in firmware, or in anycombination of these,

In a still further embodiment, each machine M1, M2 . . . Mn receives theunmodified asset (such as class or object) inclusive of one or morememory manipulation operation(s), but modifies the operations and thenloads the asset (such as class or object) consisting of the now modifiedoperations. Although one machine, such as the master or primary machinemay customize or perform a different modification to the memorymanipulation operation(s) sent to each machine, this embodiment morereadily enables the modification carried out by each machine to beslightly different. It can thereby be enhanced, customized, and/oroptimized based upon its particular machine architecture, hardwareprocessor, memory, configuration, operating system, or other factors yetstill be similar, coherent and consistent with the other machines andwith all other similar modifications.

In all of the described instances or embodiments, the supply or thecommunication of the asset code (such as class code or object code) tothe machines M1, M2 . . . Mn and optionally inclusive of a machine X,can be branched, distributed or communication among and between thedifferent machines in any combination or permutation; such as byproviding direct machine to machine communication (for example, M2supplies each of M1, M3, M4 etc. directly), or by providing or usingcascaded or sequential communication (for example, M2 supplies M1 whichthen supplies M3 which then supplies M4, and so on) or a combination ofthe direct and cascaded and/or sequential.

The abovedescribed arrangement needs to be varied in the situation wherethe modification relates to a cleanup routine, finalization or similar,which is only to be carried out by one of the plurality of computers Inthis variation of this “master/slave” or “primary/secondary”arrangement, machine M2 loads the asset (such as class or object)inclusive of a cleanup routine in unmodified form on machine M2, andthen (for example, M2 or each local machine) deletes the unmodifiedcleanup routine that had been present on the machine in whole or partfrom the asset (such as class or object) and loads by means of acomputer communications network the modified code for the asset with thenow modified or deleted cleanup routine on the other machines. Thus inthis instance the modification is not a transformation, instrumentation,translation or compilation of the asset cleanup routine but a deletionof the cleanup routine on all machines except one. In one embodiment,the actual code-block of the finalization or cleanup routine is deletedon all machines except one, and this last machine therefore is the onlymachine that can execute the finalization routine because all othermachines have deleted the finalization routine. One benefit of thisapproach is that no conflict arises between multiple machines executingthe same finalization routine because only one machine has the routine.

The process of deleting the cleanup routine in its entirety can eitherbe performed by the “master” machine (such as machine M2 or some othermachine such as machine X) or alternatively by each other machine M1, M3. . . Mn upon receipt of the unmodified asset. An additional variationof this “master/slave” or “primary/secondary” arrangement is to use ashared storage device such as a shared file system, or a shareddocument/file repository such as a shared database as means ofexchanging the code for the asset, class or object between machines M1,M2 . . . Mn and optionally the server machine X.

In a further arrangement, a particular machine, say M1, loads theunmodified asset (such as class or object) inclusive of a finalizationor cleanup routine and all the other machines M2, M3 . . . Mn perform amodification to delete the cleanup routine of the asset (such as classor object) and load the modified version.

In a still further arrangement, the machines M1, M2 . . . Mn, may sendsome or all load requests to the additional server machine X, whichperforms the modification to the application program code 50 (includingor consisting of assets, and/or classes, and/or objects) and inclusiveof finalization or cleanup routine(s), via any of the afore mentionedmethods, and returns in the modified application program code inclusiveof the now modified finalization or cleanup routine(s) to each of themachines M1 to Mn, and these machines in turn load the modifiedapplication program code inclusive of the modified routine(s) locally.In this arrangement, machines M1 to Mn forward all load requests tomachine X, which returns a modified application program code inclusiveof modified finalization or cleanup routine(s) to each machine. Themodifications performed by machine X can include any of themodifications described. This arrangement may of course be applied tosome only of the machines whilst other arrangements described herein areapplied to others of the machines.

The abovementioned embodiment in which the code of the JAVAinitialisation routine is modified, is based upon the assumption thateither the run time system (say, JAVA HOTSPOT VIRTUAL MACHINE written inC and JAVA) or the operating system (LINUX written in C and Assembler,for example) of each machine M1 . . . Mn will call the JAVAinitialisation routine. It is possible to leave the JAVA initialisationroutine unamended and instead amend the LINUX or HOTSPOT routine whichcalls the JAVA initialisation routine, so that if the object or class isalready loaded, then the JAVA initialisation routine is not called. Inorder to embrace such an arrangement the term “initialisation routine”is to be understood to include within its scope both the JAVAinitialisation routine and the “combination” of the JAVA initialisationroutine and the LINUX or HOTSPOT code fragments which call or initiatesthe JAVA initialisation routine.

The abovementioned embodiment in which the code of the JAVA finalisationor clean up routine is modified, is based upon the assumption thateither the run time system (say, JAVA HOTSPOT VIRTUAL MACHINE written inC and JAVA) or the operating system (LINUX written in C and Assembler,for example) of each machine M1 . . . Mn will call the JAVA finalisationroutine. It is possible to leave the JAVA finalisation routine unamendedand instead amend the LINUX or HOTSPOT routine which calls the JAVAfinalisation routine, so that if the object or class is not to bedeleted, then the JAVA finalisation routine is not called. In order toembrace such an arrangement the term “finalisation routine” is to beunderstood to include within its scope both the JAVA finalisationroutine and the “combination” of the JAVA finalisation routine and theLINUX or HOTSPOT code fragments which call or initiate the JAVAfinalisation routine.

The abovementioned embodiment in which the code of the JAVAsynchronization routine is modified, is based upon the assumption thateither the run time system (say, JAVA HOTSPOT VIRTUAL MACHINE written inC and JAVA) or the operating system (LINUX written in C and Assembler,for example) of each machine M1 . . . Mn will normally acquire the lockon the local machine (say M2) but not on any other machines (M1, M3 . .. Mn). It is possible to leave the JAVA synchronization routineunamended and instead amend the LINUX or HOTSPOT routine which acquiresthe lock locally, so that it correspondingly acquires the lock on allother machines as well. In order to embrace such an arrangement the term“synchronization routine” is to be understood to include within itsscope both the JAVA synchronization routine and the “combination” of theJAVA synchronization routine and the LINUX or HOTSPOT code fragmentswhich perform lock acquisition and release.

The terms object and class used herein are derived from the JAVAenvironment and are intended to embrace similar terms derived fromdifferent environments such as dynamically linked libraries (DLL), orobject code packages, or function unit or memory locations.

Those skilled in the programming arts will be aware that when additionalcode or instructions is/are inserted into an existing code orinstruction set to modify same, the existing code or instruction set maywell require further modification (such as for example, by re-numberingof sequential instructions) so that offsets, branching, attributes, markup and the like are catered for.

Similarly, in the JAVA language memory locations include, for example,both fields and array types. The above description deals with fields andthe changes required for array types are essentially the same mutatismutandis. Also the present invention is equally applicable to similarprogramming languages (including procedural, declarative and objectorientated) to JAVA including Microsoft.NET platform and architecture(Visual Basic, Visual C/C⁺⁺, and C#) FORTRAN, C/C⁺⁺, COBOL, BASIC etc.

The terms object and class used herein are derived from the JAVAenvironment and are intended to embrace similar terms derived fromdifferent environments such as dynamically linked libraries (DLL), orobject code packages, or function unit or memory locations.

Various means are described relative to embodiments of the invention,including for example but not limited to lock means, distributed runtime means, modifier or modifying means, and the like. In at least oneembodiment of the invention, any one or each of these various means maybe implemented by computer program code statements or instructions(possibly including by a plurality of computer program code statementsor instructions) that execute within computer logic circuits,processors, ASICs, microprocessors, microcontrollers or other logic tomodify the operation of such logic or circuits to accomplish the recitedoperation or function. In another embodiment, any one or each of thesevarious means may be implemented in firmware and in other embodimentssuch may be implemented in hardware. Furthermore, in at least oneembodiment of the invention, any one or each of these various means maybe implemented by a combination of computer program software, firmware,and/or hardware.

Any and each of the afore described methods, procedures, and/or routinesmay advantageously be implemented as a computer program and/or computerprogram product stored on any tangible media or existing in electronic,signal, or digital form. Such computer program or computer programproducts comprising instructions separately and/or organized as modules,programs, subroutines, or in any other way for execution in processinglogic such as in a processor or microprocessor of a computer, computingmachine, or information appliance; the computer program or computerprogram products modifying the operation of the computer in which itexecutes or on a computer coupled with, connected to, or otherwise insignal communications with the computer on which the computer program orcomputer program product is present or executing. Such a computerprogram or computer program product modifies the operation andarchitectural structure of the computer, computing machine, and/orinformation appliance to alter the technical operation of the computerand realize the technical effects described herein.

The invention may therefore includes a computer program productcomprising a set of program instructions stored in a storage medium orexisting electronically in any form and operable to permit a pluralityof computers to carry out any of the methods, procedures, routines, orthe like as described herein including in any of the claims.

Furthermore, the invention includes a plurality of computersinterconnected via a communication network or other communications linkor path and each operable to substantially simultaneously orconcurrently execute the same or a different portion of an applicationcode written to operate on only a single computer on a correspondingdifferent one of computers. The computers are programmed to carry outany of the methods, procedures. or routines described in thespecification or set forth in any of the claims, on being loaded with acomputer program product. Similarly, the invention also includes withinits scope a single computer arrayed to co-operate with like, orsubstantially similar, computers to form a multiple computer system.

The term “compromising” (and its grammatical variations) as used hereinis used in the inclusive sense of “having” or “including” and not in theexclusive sense of “consisting only of”.

COPYRIGHT NOTICE

This patent specification and the Annexures which form a part thereofcontains material which is subject to copyright protection. Thecopyright owner (which is the applicant) has no objection to thereproduction of this patent specification or related materials frompublicly available associated Patent Office files for the purposes ofreview, but otherwise reserves all copyright whatsoever. In particular,the various instructions are not to be entered into a computer withoutthe specific prior written approval of the copyright owner.

ANNEXURE A

The following are program listings in the JAVA language:

A1. This first excerpt is part of the modification code. It searchesthrough the code array, and when it finds a putstatic instruction(opcode 178), it implements the modifications.

// START byte[ ] code = Code_attribute.code;  // Bytecode of a givenmethod in  // a given classfile. int code_length =Code_attribute.code_length; int DRT = 99;   // Location of theCONSTANT_Methodref_info   // for the DRT.alert( ) method. for (int i=0;i<code_length; i++){   if ((code[i] & 0xff) == 179){ // Putstaticinstruction.     System.arraycopy(code, i+3, code, i+6,code_length−(i+3));     code[i+3] = (byte) 184; // Invokestaticinstruction for the // DRT.alert( ) method.     code[i+4] = (byte)((DRT >>> 8) & 0xff);     code[i+5] = (byte) (DRT & 0xff);   } } // ENDA2. This second excerpt is part of the DRT.alert () method, This is thebody of the DRT.alert() method when it is called.

// START public static void alert( ){   synchronized (ALERT_LOCK){   ALERT_LOCK.notify( ); // Alerts a waiting DRT thread in the   background.   } } // ENDA3. This third excerpt is part of the DRT Sending. This code fragmentshows the DRT in a separate thread, after being notified, sending thevalue across the network.

// START MulticastSocket ms = DRT.getMulticastSocket( );  // Themulticast  // socket used by  // the DRT for  communication. bytenameTag = 33;   // This is the “name tag” on the network for   // thisfield. Field field = modifiedClass.getDeclaredField(“myField1”); //Stores // the field // from the // modified // class. // In thisexample, the field is a byte field. while (DRT.isRunning( )){ synchronized (ALERT_LOCK){   ALERT_LOCK.wait( ); // The DRT thread iswaiting for the // alert method to be called.   byte[ ] b = new byte[]{nameTag, field.getByte(null)}; // Stores // the // nameTag // and the// value // of the // field from // the // modified // class in abuffer.   DatagramPacket dp = new DatagramPacket(b, 0, b.length);  ms.send(dp); // Send the buffer out across the network.  } }A4. The fourth excerpt is part of the DRT receiving. This is a fragmentof code to receive a DRT sent alert over the network.

// START MulticastSocket ms = DRT.getMulticastSocket( ); // Themulticast socket // used by the DRT for // communication. DatagramPacketdp = new DatagramPacket(new byte[2], 0, 2); byte nameTag = 33;    //This is the “name tag” on the network for    // this field. Field field= modifiedClass.getDeclaredField(“myField1”); // Stores the // fieldfrom // the // modified class. // In this example, the field is a bytefield. while (DRT.isRunning){   ms.receive(dp); // Receive thepreviously sent buffer from the   network.   byte[ ] b = dp.getData( );  if (b[0] == nameTag){  // Check the nametags match.    field.setByte(null, b[1]); // Write the value from the network //packet into the field location in memory.   } } // ENDA5. The fifth excerpt is an example application before modification hasoccurred.

Method void setValues(int, int)  0 iload_1  1 putstatic #3 <Field intstaticValue>  4 aload_0  5 iload_2  6 putfield #2 <Field intinstanceValue>  9 returnA6. The sixth excerpt is the same example application in 5 aftermodification has been performed. The modifications are highlighted inbold.

Method void setValues(int, int)  0 iload_1  1 putstatic #3 <Field intstaticValue>  4 ldc #4 <String “example”>  6 iconst — 0  7 invokestatic#5 <Method void alert(java.lang.Object, int)>  10 aload_0  11 iload_2 12 putfield #2 <Field int instanceValue>  15 aload — 0  16 iconst — 1 17 invokestatic #5 <Method void alert(java.lang.Object, int)>  20returnA7. The seventh excerpt is the source-code of the example applicationused in excerpt 5 and 6.

import java.lang.*; public class example{   /** Shared static field. */  public static int staticValue = 0;   /** Shared instance field. */  public int instanceValue = 0;   /** Example method that writes tomemory (instance field). */   public void setValues(int a, int b){   staticValue = a;    instanceValue = b;   } }A8. The eighth excerpt is the source-code of FieldAlert, which alertsthe “distributed run-time” to propagate a changed value.

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class FieldAlert{   /** Table of alerts. */   publicfinal static Hashtable alerts = new Hashtable( );   /** Object handle.*/   public Object reference = null;   /** Table of field alerts forthis object. */   public boolean[ ] fieldAlerts = null;   /**Constructor. */   public FieldAlert(Object o, int initialFieldCount){   reference = o;    fieldAlerts = new boolean[initialFieldCount];   }  /** Called when an application modifies a value. (Both objects and    classes) */   public static void alert(Object o, int fieldID){    //Lock the alerts table.    synchronized (alerts){      FieldAlert alert =(FieldAlert) alerts.get(o);      if (alert == null){  // This objecthasn't been alerted already,  // so add to alerts table.       alert =new FieldAlert(o, fieldID + 1);       alerts.put(o, alert);      }     if (fieldID >= alert.fieldAlerts.length){       // Ok, enlargefieldAlerts array.       boolean[ ] b = new boolean[fieldID+1];      System.arraycopy(alert.fieldAlerts, 0, b, 0,        alert.fieldAlerts.length);       alert.fieldAlerts = b;      }     // Record the alert.      alert.fieldAlerts[fieldID] = true;     // Mark as pending.      FieldSend.pending = true;  // Signal thatthere is one or more  // propagations waiting.      // Finally, notifythe waiting FieldSend thread(s)      if (FieldSend.waiting){      FieldSend.waiting = false;       alerts.notify( );      }    }   }}A9. The ninth excerpt is the source code of FieldSend, which propagateschanges values alerted to it via FieldAlert

import java.lang.*; import java.lang.reflect.*; import java.util.*;import java.net.*; import java.io.*; public class FieldSend implementsRunnable{   /** Protocol specific values. */   public final static intCLOSE = −1;   public final static int NACK = 0;   public final staticint ACK = 1;   public final static int PROPAGATE_OBJECT = 10;   publicfinal static int PROPAGATE_CLASS = 20;   /** FieldAlert network values.*/   public final static String group =   System.getProperty(“FieldAlert_network_group”);   public final staticint port =   Integer.parseInt(System.getProperty(“FieldAlert_network_port”));  /** Table of global ID's for local objects. (hashcode-to-globalID    mappings) */   public final static Hashtable objectToGlobalID = newHashtable( );   /** Table of global ID's for local classnames.(classname-to-globalID     mappings) */   public final static HashtableclassNameToGlobalID = new Hashtable( );   /** Pending. True if apropagation is pending. */   public static boolean pending = false;  /** Waiting. True if the FieldSend thread(s) are waiting. */   publicstatic boolean waiting = false;   /** Background send thread. Propagatesvalues as this thread is alerted     to their alteration. */   publicvoid run( ){    System.out.println(“FieldAlert_network_group=” + group);   System.out.println(“FieldAlert_network_port=” + port);    try{     // Create a DatagramSocket to send propagated field values.     DatagramSocket datagramSocket =       new DatagramSocket(port,InetAddress.getByName(group));      // Next, create the buffer andpacket for all transmissions.      byte[ ] buffer = new byte[512];  //Working limit of 512 bytes  // per packet.      DatagramPacketdatagramPacket =       new DatagramPacket(buffer, 0, buffer.length);     while (!Thread.interrupted( )){       Object[ ] entries = null;   // Lock the alerts table.    synchronized (FieldAlert.alerts){     // Await for an alert to propagate something.      while(!pending){       waiting = true;       FieldAlert.alerts.wait( );      waiting = false;      56      pending = false;      entries =FieldAlert.alerts.entrySet( ).toArray( );      // Clear alerts once wehave copied them.      FieldAlert.alerts.clear( );    }    // Processeach object alert in turn.    for (int i=0; i<entries.length; i++){     FieldAlert alert = (FieldAlert) entries[i];      int index = 0;     datagramPacket.setLength(buffer.length);      Object reference =null;      if (alert.reference instanceof String){       //PROPAGATE_CLASS field operation.       buffer[index++] = (byte)((PROPAGATE_CLASS >> 24) & 0xff);       buffer[index++] = (byte)((PROPAGATE_CLASS >> 16) & 0xff);       buffer[index++] = (byte)((PROPAGATE_CLASS >> 8) & 0xff);       buffer[index++] = (byte)((PROPAGATE_CLASS >> 0) & 0xff);       String name = (String)alert.reference;       int length = name.length( );      buffer[index++] = (byte) ((length >> 24) & 0xff);      buffer[index++] = (byte) ((length >> 16) & 0xff);      buffer[index++] = (byte) ((length >> 8) & 0xff);      buffer[index++] = (byte) ((length >> 0) & 0xff);       byte[ ]bytes = name.getBytes( );       System.arraycopy(bytes, 0, buffer,index, length);       index += length;      }else{         //PROPAGATE_OBJECT field operation.       buffer[index++] =        (byte) ((PROPAGATE_OBJECT >> 24) & 0xff);       buffer[index++]=         (byte) ((PROPAGATE_OBJECT >> 16) & 0xff);      buffer[index++] = (byte) ((PROPAGATE_OBJECT >> 8) & 0xff);      buffer[index++] = (byte) ((PROPAGATE_OBJECT >> 0) & 0xff);      int globalID = ((Integer)        objectToGlobalID.get(alert.reference)).intValue( );      buffer[index++] = (byte) ((globalID >> 24) & 0xff);      buffer[index++] = (byte) ((globalID >> 16) & 0xff);      buffer[index++] = (byte) ((globalID >> 8) & 0xff);      buffer[index++] = (byte) ((globalID >> 0) & 0xff);       reference= alert.reference;      }      // Use reflection to get a table offields that correspond to      // the field indexes used internally.     Field[ ] fields = null;      if (reference == null){       fields =FieldLoader.loadClass((String)        alert.reference).getDeclaredFields( );      }else{       fields= alert.reference.getClass( ).getDeclaredFields( );      }      // Nowencode in batch mode the fieldID/value pairs.      for (int j=0;j<alert.fieldAlerts.length; j++){       if (alert.fieldAlerts[j] ==false)         continue;       buffer[index++] = (byte) ((j >> 24) &0xff);       buffer[index++] = (byte) ((j >> 16) & 0xff);      buffer[index++] = (byte) ((j >> 8) & 0xff);        buffer[index++] = (byte) ((j >> 0) & 0xff);       // Encodevalue.       Class type = fields[j].getType( );       if (type ==Boolean.TYPE){         buffer[index++] =(byte)         (fields[j].getBoolean(reference)? 1 : 0);       }else if (type== Byte.TYPE){         buffer[index++] = fields[j].getByte(reference);      }else if (type == Short.TYPE){         short v =fields[j].getShort(reference);         buffer[index++] = (byte) ((v >>8) & 0xff);         buffer[index++] = (byte) ((v >> 0) & 0xff);      }else if (type == Character.TYPE){         char v =fields[j].getChar(reference);         buffer[index++] = (byte) ((v >> 8)& 0xff);         buffer[index++] = (byte) ((v >> 0) & 0xff);       }elseif (type == Integer.TYPE){         int v = fields[j].getInt(reference);        buffer[index++] = (byte) ((v >> 24) & 0xff);        buffer[index++] = (byte) ((v >> 16) & 0xff);        buffer[index++] = (byte) ((v >> 8) & 0xff);        buffer[index++] = (byte) ((v >> 0) & 0xff);       }else if (type== Float.TYPE){         int v = Float.floatToIntBits(         fields[j].getFloat(reference));         buffer[index++] =(byte) ((v >> 24) & 0xff);         buffer[index++] = (byte) ((v >> 16) &0xff);         buffer[index++] = (byte) ((v >> 8) & 0xff);        buffer[index++] = (byte) ((v >> 0) & 0xff);       }else if (type== Long.TYPE){         long v = fields[j].getLong(reference);        buffer[index++] = (byte) ((v >> 56) & 0xff);        buffer[index++] = (byte) ((v >> 48) & 0xff);        buffer[index++] = (byte) ((v >> 40) & 0xff);        buffer[index++] = (byte) ((v >> 32) & 0xff);        buffer[index++] = (byte) ((v >> 24) & 0xff);        buffer[index++] = (byte) ((v >> 16) & 0xff);        buffer[index++] = (byte) ((v >> 8) & 0xff);        buffer[index++] = (byte) ((v >> 0) & 0xff);       }else if (type== Double.TYPE){         long v = Double.doubleToLongBits(            fields[j].getDouble(reference));            buffer[index++]= (byte) ((v >> 56) & 0xff);            buffer[index++] = (byte) ((v >>48) & 0xff);            buffer[index++] = (byte) ((v >> 40) & 0xff);           buffer[index++] = (byte) ((v >> 32) & 0xff);           buffer[index++] = (byte) ((v >> 24) & 0xff);           buffer[index++] = (byte) ((v >> 16) & 0xff);           buffer[index++] = (byte) ((v >> 8) & 0xff);           buffer[index++] = (byte) ((v >> 0) & 0xff);          }else{           throw new AssertionError(“Unsupported type.”);          }        }         // Now set the length of the datagrampacket.        datagramPacket.setLength(index);         // Now send the packet.        datagramSocket.send(datagramPacket);       }      }    }catch(Exception e){      throw new AssertionError(“Exception: ” + e.toString());    }   } }A10. The tenth excerpt is the source-code of FieldReceive, whichreceives propagated changed values sent via FieldSend.

import java.lang.*; import java.lang.reflect.*; import java.util.*;import java.net.*; import java.io.*; public class FieldReceiveimplements Runnable{   /** Protocol specific values. */   public finalstatic int CLOSE = −1;   public final static int NACK = 0;   publicfinal static int ACK = 1;   public final static int PROPAGATE_OBJECT =10;   public final static int PROPAGATE_CLASS = 20;   /** FieldAlertnetwork values. */   public final static String group =   System.getProperty(“FieldAlert_network_group”);   public final staticint port =   Integer.parseInt(System.getProperty(“FieldAlert_network_port”));  /** Table of global ID's for local objects. (globalID-to-hashcode    mappings) */   public final static Hashtable globalIDToObject = newHashtable( );   /** Table of global ID's for local classnames.(globalID-to-classname     mappings) */ public final static HashtableglobalIDToClassName = new Hashtable( ); /** Called when an applicationis to acquire a lock. */ public void run( ){  System.out.println(“FieldAlert_network_group=” + group);  System.out.println(“FieldAlert_network_port=” + port);   try{    //Create a DatagramSocket to send propagated field values from   MulticastSocket multicastSocket = new MulticastSocket(port);   multicastSocket.joinGroup(InetAddress.getByName(group));    // Next,create the buffer and packet for all transmissions.    byte[ ] buffer =new byte[512];      // Working limit      // of 512 bytes      perpacket.    DatagramPacket datagramPacket =      newDatagramPacket(buffer, 0, buffer.length);    while (!Thread.interrupted()){      // Make sure to reset length.     datagramPacket.setLength(buffer.length);      // Receive the nextavailable packet.      multicastSocket.receive(datagramPacket);      intindex = 0, length = datagramPacket.getLength( );      // Decode thecommand.      int command = (int) (((buffer[index++] & 0xff) << 24)      | ((buffer[index++] & 0xff) << 16)       | ((buffer[index++] &0xff) << 8)       | (buffer[index++] & 0xff));      if (command ==PROPAGATE_OBJECT){ // Propagate // operation for object fields.       //Decode global id.       int globalID = (int) (((buffer[index++] & 0xff)<< 24)         | ((buffer[index++] & 0xff) << 16)         |((buffer[index++] & 0xff) << 8)         | (buffer[index++] & 0xff));      // Now, need to resolve the object in question.       Objectreference = globalIDToObject.get(         new Integer(globalID));      // Next, get the array of fields for this object.       Field[ ]fields = reference.getClass( ).getDeclaredFields( );       while (index< length){         // Decode the field id.         int fieldID = (int)(((buffer[index++] & 0xff) << 24)          | ((buffer[index++] & 0xff)<< 16)          | ((buffer[index++] & 0xff) << 8)          |(buffer[index++] & 0xff));         // Determine value length based oncorresponding field         // type.         Field field =fields[fieldID];         Class type = field.getType( );         if (type== Boolean.TYPE){          boolean v = (buffer[index++] == 1 ? true :false);          field.setBoolean(reference, v);         }else if (type== Byte.TYPE){          byte v = buffer[index++];         field.setByte(reference, v);         }else if (type ==Short.TYPE){          short v = (short) (((buffer[index++] & 0xff) << 8)           | (buffer[index++] & 0xff));         field.setShort(reference, v);         }else if (type ==Character.TYPE){          char v = (char) (((buffer[index++] & 0xff) <<8)            | (buffer[index++] & 0xff));         field.setChar(reference, v);         }else if (type ==Integer.TYPE){          int v = (int) (((buffer[index++] & 0xff) << 24)           | ((buffer[index++] & 0xff) << 16)            |((buffer[index++] & 0xff) << 8)            | (buffer[index++] & 0xff));         field.setInt(reference, v);         }else if (type ==Float.TYPE){          int v = (int) (((buffer[index++] & 0xff) << 24)           | ((buffer[index++] & 0xff) << 16)            |((buffer[index++] & 0xff) << 8)            | (buffer[index++] & 0xff));         field.setFloat(reference, Float.intBitsToFloat(v));        }else if (type == Long.TYPE){          long v = (long)(((buffer[index++] & 0xff) << 56)            | ((buffer[index++] & 0xff)<< 48)            | ((buffer[index++] & 0xff) << 40)            |((buffer[index++] & 0xff) << 32)            | ((buffer[index++] & 0xff)<< 24)            | ((buffer[index++] & 0xff) << 16)            |((buffer[index++] & 0xff) << 8)            | (buffer[index++] & 0xff));         field.setLong(reference, v);         }else if (type ==Double.TYPE){          long v = (long) (((buffer[index++] & 0xff) << 56)           | ((buffer[index++] & 0xff) << 48)            |((buffer[index++] & 0xff) << 40)            | ((buffer[index++] & 0xff)<< 32)            | ((buffer[index++] & 0xff) << 24)            |((buffer[index++] & 0xff) << 16)            | ((buffer[index++] & 0xff)<< 8)            | (buffer[index++] & 0xff));         field.setDouble(reference,         Double.longBitsToDouble(v));         }else{          throw newAssertionError(“Unsupported type.”);         }       }      }else if(command == PROPAGATE_CLASS){  // Propagate  // an update  to class fields.       // Decode the classname.       int nameLength = (int)(((buffer[index++] & 0xff) << 24)         | ((buffer[index++] & 0xff) <<16)         | ((buffer[index++] & 0xff) << 8)         | (buffer[index++]& 0xff));       String name = new String(buffer, index, nameLength);      index += nameLength;       // Next, get the array of fields forthis class.       Field[ ] fields =        FieldLoader.loadClass(name).getDeclaredFields( );         //Decode all batched fields included in this propagation         //packet.         while (index < length){          // Decode the field id.         int fieldID = (int) (((buffer[index++] & 0xff) << 24)           | ((buffer[index++] & 0xff) << 16)            |((buffer[index++] & 0xff) << 8)            | (buffer[index++] & 0xff));         // Determine field type to determine value length.         Field field = fields[fieldID];          Class type =field.getType( );          if (type == Boolean.TYPE){            booleanv = (buffer[index++] == 1 ?            true : false);           field.setBoolean(null, v);          }else if (type ==Byte.TYPE){            byte v = buffer[index++];           field.setByte(null, v);          }else if (type ==Short.TYPE){            short v = (short) (((buffer[index++]           & 0xff) << 8)             | (buffer[index++] & 0xff));           field.setShort(null, v);          }else if (type ==Character.TYPE){            char v = (char) (((buffer[index++] & 0xff)<< 8)             | (buffer[index++] & 0xff));           field.setChar(null, v);          }else if (type ==Integer.TYPE){            int v = (int) (((buffer[index++] & 0xff) <<24)             | ((buffer[index++] & 0xff) << 16)             |((buffer[index++] & 0xff) << 8)             | (buffer[index++] & 0xff));           field.setInt(null, v);          }else if (type ==Float.TYPE){            int v = (int) (((buffer[index++] & 0xff) << 24)            | ((buffer[index++] & 0xff) << 16)             |((buffer[index++] & 0xff) << 8)             | (buffer[index++] & 0xff));           field.setFloat(null, Float.intBitsToFloat(v));          }elseif (type == Long.TYPE){            long v = (long) (((buffer[index++]           & 0xff) << 56)             | ((buffer[index++] & 0xff) << 48)            | ((buffer[index++] & 0xff) << 40)             |((buffer[index++] & 0xff) << 32)             | ((buffer[index++] & 0xff)<< 24)             | ((buffer[index++] & 0xff) << 16)             |((buffer[index++] & 0xff) << 8)             | (buffer[index++] & 0xff));           field.setLong(null, v);          }else if (type ==Double.TYPE){            long v = (long) (((buffer[index++]            &0xff) << 56)             | ((buffer[index++] & 0xff) << 48)            | ((buffer[index++] & 0xff) << 40)             |((buffer[index++] & 0xff) << 32)             | ((buffer[index++] & 0xff)<< 24)             | ((buffer[index++] & 0xff) << 16)             |((buffer[index++] & 0xff) << 8)             | (buffer[index++] & 0xff));           field.setDouble(null,            Double.longBitsToDouble(v));         }else{     // Unsupported field type.            throw newAssertionError(“Unsupported type.”);          }         }       }      }   }catch (Exception e){      throw new AssertionError(“Exception: ” +e.toString( ));    }   } }A11. FieldLoader.javaThis excerpt is the source-code of FieldLoader, which modifies anapplication as it is being loaded.

import java.lang.*; import java.io.*; import java.net.*; public classFieldLoader extends URLClassLoader{  public FieldLoader(URL[ ] urls){  super(urls);  }  protected Class findClass(String name)  throwsClassNotFoundException{   ClassFile cf = null;   try{   BufferedInputStream in =     new BufferedInputStream(findResource(    name.replace(‘.’, ‘/’).concat(“.class”)).openStream( ));    cf = newClassFile(in);   }catch (Exception e){throw newClassNotFoundException(e.toString( ));}   // Class-wide pointers to theldc and alert index.   int ldcindex = −1;   int alertindex = −1;   for(int i=0; i<cf.methods_count; i++){    for (int j=0;j<cf.methods[i].attributes_count; j++){     if(!(cf.methods[i].attributes[j] instanceof Code_attribute))     continue;     Code_attribute ca = (Code_attribute)cf.methods[i].attributes[j];     boolean changed = false;     for (intz=0; z<ca.code.length; z++){      if ((ca.code[z][0] & 0xff) == 179){ //Opcode for a PUTSTATIC // instruction.       changed = true;       //The code below only supports fields in this class.       // Thus, firstoff, check that this field is local to this       // class.      CONSTANT_Fieldref_info fi = (CONSTANT_Fieldref_info)     cf.constant_pool[(int) (((ca.code[z][1] & 0xff) << 8) |     (ca.code[z][2] & 0xff))];     CONSTANT_Class_info ci =(CONSTANT_Class_info)      cf.constant_pool[fi.class_index];     StringclassName =      cf.constant_pool[ci.name_index].toString( );     if(!name.equals(className)){      throw new AssertionError(“This code onlysupports fields ”       “local to this class”);     }     // Ok, nowsearch for the fields name and index.     int index = 0;    CONSTANT_NameAndType_info ni = (CONSTANT_NameAndType_info)     cf.constant_pool[fi.name_and_type_index];     String fieldName =     cf.constant_pool[ni.name_index].toString( );     for (int a=0;a<cf.fields_count; a++){      String fn = cf.constant_pool[      cf.fields[a].name_index].toString( );      if(fieldName.equals(fn)){       index = a;       break;      }     }    // Next, realign the code array, making room for the     //insertions.     byte[ ][ ] code2 = new byte[ca.code.length+3][ ];    System.arraycopy(ca.code, 0, code2, 0, z+1);    System.arraycopy(ca.code, z+1, code2, z+4,     ca.code.length−(z+1));     ca.code = code2;     // Next, insert theLDC_W instruction.     if (ldcindex == −1){      CONSTANT_String_infocsi =       new CONSTANT_String_info(ci.name_index);      cp_info[ ] cpi= new cp_info[cf.constant_pool.length+1];     System.arraycopy(cf.constant_pool, 0, cpi, 0,      cf.constant_pool.length);      cpi[cpi.length − 1] = csi;     ldcindex = cpi.length−1;      cf.constant_pool = cpi;     cf.constant_pool_count++;     }     ca.code[z+1] = new byte[3];    ca.code[z+1][0] = (byte) 19;     ca.code[z+1][1] = (byte)((ldcindex >> 8) & 0xff);     ca.code[z+1][2] = (byte) (ldcindex &0xff);     // Next, insert the SIPUSH instruction.     ca.code[z+2] =new byte[3];     ca.code[z+2][0] = (byte) 17;     ca.code[z+2][1] =(byte) ((index >> 8) & 0xff);     ca.code[z+2][2] = (byte) (index &0xff);     // Finally, insert the INVOKESTATIC instruction.     if(alertindex == −1){      // This is the first time this class isencourtering the      // alert instruction, so have to add it to theconstant      // pool.      cp_info[ ] cpi = newcp_info[cf.constant_pool.length+6];     System.arraycopy(cf.constant_pool, 0, cpi, 0,      cf.constant_pool.length);      cf.constant_pool = cpi;     cf.constant_pool_count += 6;      CONSTANT_Utf8_info u1 =       newCONSTANT_Utf8_info(“FieldAlert”);     cf.constant_pool[cf.constant_pool.length−6] = u1;     CONSTANT_Class_info c1 = new CONSTANT_Class_info(      cf.constant_pool_count−6);     cf.constant_pool[cf.constant_pool.length−5] = c1;      u1 = newCONSTANT_Utf8_info(“alert”);     cf.constant_pool[cf.constant_pool.length−4] = u1;      u1 = newCONSTANT_Utf8_info(“(Ljava/lang/Object;I)V”);     cf.constant_pool[cf.constant_pool.length−3] = u1;     CONSTANT_NameAndType_info n1 =       new CONSTANT_NameAndType_info(      cf.constant_pool.length−4, cf.constant_pool.length−3);     cf.constant_pool[cf.constant_pool.length−2] = n1;     CONSTANT_Methodref_info m1 = new CONSTANT_Methodref_info(      cf.constant_pool.length−5, cf.constant_pool.length−2);     cf.constant_pool[cf.constant_pool.length−1] = m1;      alertindex =cf.constant_pool.length−1;     }     ca.code[z+3] = new byte[3];    ca.code[z+3][0] = (byte) 184;     ca.code[z+3][1] = (byte)((alertindex >> 8) & 0xff);     ca.code[z+3][2] = (byte) (alertindex &0xff);     // And lastly, increase the CODE_LENGTH and ATTRIBUTE_LENGTH    // values.     ca.code_length += 9;     ca.attribute_length += 9;   }   }   // If we changed this method, then increase the stack size byone.   if (changed){    ca.max_stack++;     // Just to make sure.   }  }} try{  ByteArrayOutputStream out = new ByteArrayOutputStream( ); cf.serialize(out);  byte[ ] b = out.toByteArray( );  returndefineClass(name, b, 0, b.length); }catch (Exception e){  throw newClassNotFoundException(name); }  } }A12. Attribute_(—)_l info.javaConvience class for representing attribute_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** This abstract class representsall types of attribute_info  *  that are used in the JVM specifications. *  *  All new attribute_info subclasses are to always inherit from this *  class.  */ public abstract class attribute_info{   public intattribute_name_index;   public int attribute_length;   /** This is usedby subclasses to register themselves    *  to their parent classFile.   */   attribute_info(ClassFile cf){ }   /** Used during inputserialization by ClassFile only. */   attribute_info(ClassFile cf,DataInputStream in)     throws IOException{     attribute_name_index =in.readChar( );     attribute_length = in.readInt( );   }   /** Usedduring output serialization by ClassFile only. */   voidserialize(DataOutputStream out)     throws IOException{    out.writeChar(attribute_name_index);    out.writeInt(attribute_length);   }   /** This class represents anunknown attribute_info that    *  this current version of classfilespecification does    *  not understand.    */   public final staticclass Unknown extends attribute_info{     byte[ ] info;     /** Usedduring input serialization by ClassFile only. */     Unknown(ClassFilecf, DataInputStream in)       throws IOException{       super(cf, in);      info = new byte[attribute_length];       in.read(info, 0,attribute_length);     }     /** Used during output serialization byClassFile only. */     void serialize(DataOutputStream out)       throwsIOException{       ByteArrayOutputStream baos =       newByteArrayOutputStream( );       super.serialize(out);      out.write(info, 0, attribute_length);     }   } }A13. ClassFile.javaConvience class for representing ClassFile structures.

import java.lang.*; import java.io.*; import java.util.*; /** TheClassFile follows verbatim from the JVM specification. */ public finalclass ClassFile {   public int magic;   public int minor_version;  public int major_version;   public int constant_pool_count;   publiccp_info[ ] constant_pool;   public int access_flags;   public intthis_class;   public int super_class;   public int interfaces_count;  public int[ ] interfaces;   public int fields_count;   publicfield_info[ ] fields;   public int methods_count;   public method_info[] methods;   public int attributes_count;   public attribute_info[ ]attributes;   /** Constructor. Takes in a byte stream representation andtransforms    *  each of the attributes in the ClassFile into objects toallow for    *  easier manipulation.    */   publicClassFile(InputStream ins)     throws IOException{     DataInputStreamin = (ins instanceof DataInputStream ?       (DataInputStream) ins : newDataInputStream(ins));     magic = in.readInt( );     minor_version =in.readChar( );     major_version = in.readChar( );    constant_pool_count = in.readChar( );     constant_pool = newcp_info[constant_pool_count];     for (int i=1; i<constant_pool_count;i++){       in.mark(1);       int s = in.read( );       in.reset( );      switch (s){         case 1:           constant_pool[i] = newCONSTANT_Utf8_info(this, in);           break;         case 3:          constant_pool[i] = new CONSTANT_Integer_info(this, in);          break;         case 4:           constant_pool[i] = newCONSTANT_Float_info(this, in);           break;         case 5:          constant_pool[i] = new CONSTANT_Long_info(this, in);          i++;           break;         case 6:          constant_pool[i] = new CONSTANT_Double_info(this, in);          i++;           break;         case 7:          constant_pool[i] = new CONSTANT_Class_info(this, in);          break;         case 8:           constant_pool[i] = newCONSTANT_String_info(this, in);           break;         case 9:          constant_pool[i] = new CONSTANT_Fieldref_info(this, in);          break;         case 10:           constant_pool[i] = newCONSTANT_Methodref_info(this, in);           break;         case 11:          constant_pool[i] =             newCONSTANT_InterfaceMethodref_info(this, in);           break;        case 12:           constant_pool[i] = newCONSTANT_NameAndType_info(this, in);           break;         default:          throw new ClassFormatError(“Invalid ConstantPoolTag”);       }    }     access_flags = in.readChar( );     this_class = in.readChar();     super_class = in.readChar( );     interfaces_count = in.readChar();     interfaces = new int[interfaces_count];     for (int i=0;i<interfaces_count; i++)       interfaces[i] = in.readChar( );    fields_count = in.readChar( );     fields = newfield_info[fields_count];     for (int i=0; i<fields_count; i++) {      fields[i] = new field_info(this, in);     }     methods_count =in.readChar( );     methods = new method_info[methods_count];     for(int i=0; i<methods_count; i++) {       methods[i] = newmethod_info(this, in);     }     attributes_count = in.readChar( );    attributes = new attribute_info[attributes_count];     for (int i=0;i<attributes_count; i++){       in.mark(2);       String s =constant_pool[in.readChar( )].toString( );       in.reset( );       if(s.equals(“SourceFile”))         attributes[i] = newSourceFile_attribute(this, in);       else if (s.equals(“Deprecated”))        attributes[i] = new Deprecated_attribute(this, in);       elseif (s.equals(“InnerClasses”))         attributes[i] = newInnerClasses_attribute(this, in);       else         attributes[i] = newattribute_info.Unknown(this, in);     }   }   /** Serializes theClassFile object into a byte stream. */   public voidserialize(OutputStream o)     throws IOException{     DataOutputStreamout = (o instanceof DataOutputStream ?       (DataOutputStream) o : newDataOutputStream(o));     out.writeInt(magic);    out.writeChar(minor_version);     out.writeChar(major_version);    out.writeChar(constant_pool_count);     for (int i=1;i<constant_pool_count; i++){       constant_pool[i].serialize(out);      if (constant_pool[i] instanceof CONSTANT_Long_info ∥          constant_pool[i] instanceof CONSTANT_Double_info)         i++;    }     out.writeChar(access_flags);     out.writeChar(this_class);    out.writeChar(super_class);     out.writeChar(interfaces_count);    for (int i=0; i<interfaces_count; i++)      out.writeChar(interfaces[i]);     out.writeChar(fields_count);    for (int i=0; i<fields_count; i++)       fields[i].serialize(out);    out.writeChar(methods_count);     for (int i=0; i<methods_count;i++)       methods[i].serialize(out);    out.writeChar(attributes_count);     for (int i=0;i<attributes_count; i++)       attributes[i].serialize(out);     //Flush the outputstream just to make sure.     out.flush( );   } }A14. Code_Attribute.javaConvience class for representing Code_attribute structures withinClassFiles.

import java.util.*; import java.lang.*; import java.io.*; /**  * Thecode[ ] is stored as a 2D array.  */ public final class Code_attributeextends attribute_info{   public int max_stack;   public int max_locals;  public int code_length;   public byte[ ][ ] code;   public intexception_table_length;   public exception_table[ ] exception_table;  public int attributes_count;   public attribute_info[ ] attributes;  /** Internal class that handles the exception table. */   public finalstatic class exception_table{     public int start_pc;     public intend_pc;     public int handler_pc;     public int catch_type;   }   /**Constructor called only by method_info. */   Code_attribute(ClassFilecf, int ani, int al, int ms, int ml, int cl,           byte[ ][ ] cd,int etl, exception_table[ ] et, int ac,           attribute_info[ ] a){    super(cf);     attribute_name_index = ani;     attribute_length =al;     max_stack = ms;     max_locals = ml;     code_length = cl;    code = cd;     exception_table_length = etl;     exception_table =et;     attributes_count = ac;     attributes = a;   }   /** Used duringinput serialization by ClassFile only. */   Code_attribute(ClassFile cf,DataInputStream in)     throws IOException{     super(cf, in);    max_stack = in.readChar( );     max_locals = in.readChar( );    code_length = in.readInt( );     code = new byte[code_length][ ];    int i = 0;     for (int pos=0; pos<code_length; i++){      in.mark(1);       int s = in.read( );       in.reset( );      switch (s){         case 16:         case 18:         case 21:        case 22:         case 23:         case 24:         case 25:        case 54:         case 55:         case 56:         case 57:        case 58:         case 169:         case 188:         case 196:          code[i] = new byte[2];           break;         case 17:        case 19:         case 20:         case 132:         case 153:        case 154:         case 155:         case 156:         case 157:        case 158:         case 159:         case 160:         case 161:        case 162:         case 163:         case 164:         case 165:        case 166:         case 167:         case 168:         case 178:        case 179:         case 180:         case 181:         case 182:        case 183:         case 184:         case 187:         case 189:        case 192:         case 193:         case 198:         case 199:        case 209:           code[i] = new byte[3];           break;        case 197:           code[i] = new byte[4];           break;        case 185:         case 200:         case 201:           code[i]= new byte[5];           break;         case 170:{           int pad = 3− (pos % 4);           in.mark(pad+13); // highbyte          in.skipBytes(pad+5); // lowbyte           int low =in.readInt( );           code[i] =             new byte[pad + 13 +((in.readInt( ) − low + 1) * 4)];           in.reset( );          break;         }case 171:{           int pad = 3 − (pos % 4);          in.mark(pad+9);           in.skipBytes(pad+5);          code[i] = new byte[pad + 9 + (in.readInt( ) * 8)];          in.reset( );           break;         }default:          code[i] = new byte[1];       }       in.read(code[i], 0,code[i].length);       pos += code[i].length;     }     // adjust thearray to the new size and store the size     byte[ ][ ] temp = newbyte[i][ ];     System.arraycopy(code, 0, temp, 0, i);     code = temp;    exception_table_length = in.readChar( );     exception_table =      new Code_attribute.exception_table[exception_table_length];    for (i=0; i<exception_table_length; i++){       exception_table[i] =new exception_table( );       exception_table[i].start_pc = in.readChar();       exception_table[i].end_pc = in.readChar( );      exception_table[i].handler_pc = in.readChar( );      exception_table[i].catch_type = in.readChar( );     }    attributes_count = in.readChar( );     attributes = newattribute_info[attributes_count];     for (i=0; i<attributes_count;i++){       in.mark(2);       String s = cf.constant_pool[in.readChar()].toString( );       in.reset( );       if(s.equals(“LineNumberTable”))         attributes[i] = newLineNumberTable_attribute(cf, in);       else if(s.equals(“LocalVariableTable”))         attributes[i] = newLocalVariableTable_attribute(cf, in);       else         attributes[i] =new attribute_info.Unknown(cf, in);     }   }   /** Used during outputserialization by ClassFile only.   */   void serialize(DataOutputStreamout)     throws IOException{       attribute_length = 12 + code_length +        (exception_table_length * 8);       for (int i=0;i<attributes_count; i++)         attribute_length +=attributes[i].attribute_length + 6;       super.serialize(out);      out.writeChar(max_stack);       out.writeChar(max_locals);      out.writeInt(code_length);       for (int i=0, pos=0;pos<code_length; i++){         out.write(code[i], 0, code[i].length);        pos += code[i].length;       }      out.writeChar(exception_table_length);       for (int i=0;i<exception_table_length; i++){        out.writeChar(exception_table[i].start_pc);        out.writeChar(exception_table[i].end_pc);        out.writeChar(exception_table[i].handler_pc);        out.writeChar(exception_table[i].catch_type);       }      out.writeChar(attributes_count);       for (int i=0;i<attributes_count; i++)         attributes[i].serialize(out);   } }A15. CONSTANT_Class_info.javaConvience class for representing CONSTANT_Class_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** Class subtype of a constantpool entry. */ public final class CONSTANT_Class_info extends cp_info{  /** The index to the name of this class. */   public int name_index =0;   /** Convenience constructor.    */   public CONSTANT_Class_info(intindex) {     tag = 7;     name_index = index;   }   /** Used duringinput serialization by ClassFile only. */  CONSTANT_Class_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 7)       throw newClassFormatError( );     name_index = in.readChar( );   }   /** Usedduring output serialization by ClassFile only. */   voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(tag);     out.writeChar(name_index);   } }A16. CONSTANT_Double_info.javaConvience class for representing CONSTANT_Double_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** Double subtype of a constantpool entry. */ public final class CONSTANT_Double_info extends cp_info{  /** The actual value. */   public double bytes;   publicCONSTANT_Double_info(double d){     tag = 6;     bytes = d;   }   /**Used during input serialization by ClassFile only. */  CONSTANT_Double_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 6)       throw newClassFormatError( );     bytes = in.readDouble( );   }   /** Used duringoutput serialization by ClassFile only. */   voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(tag);     out.writeDouble(bytes);     long l =Double.doubleToLongBits(bytes);   } }A17. CONSTANT_Fieldref_info.javaConvience class for representing CONSTANT_Fieldref_info structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** Fieldref subtype of a constantpool entry. */ public final class CONSTANT_Fieldref_info extendscp_info{   /** The index to the class that this field is referencing to.*/   public int class_index;   /** The name and type index this field ifreferencing to. */   public int name_and_type_index;   /** Convenienceconstructor. */   public CONSTANT_Fieldref_info(int class_index,   intname_and_type_index) {     tag = 9;     this.class_index = class_index;    this.name_and_type_index = name_and_type_index;   }   /** Usedduring input serialization by ClassFile only. */  CONSTANT_Fieldref_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 9)       throw newClassFormatError( );     class_index = in.readChar( );    name_and_type_index = in.readChar( );   }   /** Used during outputserialization by ClassFile only. */   void serialize(DataOutputStreamout)     throws IOException{     out.writeByte(tag);    out.writeChar(class_index);     out.writeChar(name_and_type_index);  } }A18. CONSTANT_Float_info.javaConvience class for representing CONSTANT_Float_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** Float subtype of a constantpool entry. */ public final class CONSTANT_Float_info extends cp_info{  /** The actual value. */   public float bytes;   publicCONSTANT_Float_info(float f){     tag = 4;     bytes = f;   }   /** Usedduring input serialization by ClassFile only. */  CONSTANT_Float_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 4)       throw newClassFormatError( );     bytes = in.readFloat( );   }   /** Used duringoutput serialization by ClassFile only. */   public voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(4);     out.writeFloat(bytes);   } }A19. CONSTANT_Integer_info.javaConvience class for representing CONSTANT_Integer_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** Integer subtype of a constantpool entry. */ public final class CONSTANT_Integer_info extends cp_info{  /** The actual value. */   public int bytes;   publicCONSTANT_Integer_info(int b) {     tag = 3;     bytes = b;   }   /**Used during input serialization by ClassFile only. */  CONSTANT_Integer_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 3)       throw newClassFormatError( );     bytes = in.readInt( );   }   /** Used duringoutput serialization by ClassFile only. */   public voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(tag);     out.writeInt(bytes);   } }A20. CONSTANT_InterfaceMethodref_info.javaConvience class for representing CONSTANT_InterfaceMethodref_infostructures within ClassFiles.

import java.lang.*; import java.io.*; /** InterfaceMethodref subtype ofa constant pool entry.  */ public final classCONSTANT_InterfaceMethodref_info extends cp_info{   /** The index to theclass that this field is referencing to. */   public int class_index;  /** The name and type index this field if referencing to. */   publicint name_and_type_index;   public CONSTANT_InterfaceMethodref_info(intclass_index,                 int name_and_type_index) {     tag = 11;    this.class_index = class_index;     this.name_and_type_index =name_and_type_index;   }   /** Used during input serialization byClassFile only. */   CONSTANT_InterfaceMethodref_info(ClassFile cf,  DataInputStream in)     throws IOException{     super(cf, in);     if(tag != 11)       throw new ClassFormatError( );     class_index =in.readChar( );     name_and_type_index = in.readChar( );   }   /** Usedduring output serialization by ClassFile only. */   voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(tag);     out.writeChar(class_index);    out.writeChar(name_and_type_index);   } }A21. CONSTANT_Long_info.javaConvience class for representing CONSTANT_Long_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** Long subtype of a constantpool entry. */ public final class CONSTANT_Long_info extends cp_info{  /** The actual value. */   public long bytes;   publicCONSTANT_Long_info(long b){     tag = 5;     bytes = b;   }   /** Usedduring input serialization by ClassFile only. */  CONSTANT_Long_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 5)       throw newClassFormatError( );     bytes = in.readLong( );   }   /** Used duringoutput serialization by ClassFile only. */   voidserialize(DataOutputStream out)     throws IOException{    out.writeByte(tag);     out.writeLong(bytes);   } }A22. CONSTANT_Methodref_info.javaConvience class for representing CONSTANT_Methodref_info structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** Methodref subtype of aconstant pool entry.  */ public final class CONSTANT_Methodref_infoextends cp_info{   /** The index to the class that this field isreferencing to. */   public int class_index;   /** The name and typeindex this field if referencing to. */   public int name_and_type_index;  public CONSTANT_Methodref_info(int class_index,   intname_and_type_index) {     tag = 10;     this.class_index = class_index;    this.name_and_type_index = name_and_type_index;   }   /** Usedduring input serialization by ClassFile only. */  CONSTANT_Methodref_info(ClassFile cf, DataInputStream in)     throwsIOException{     super(cf, in);     if (tag != 10)       throw newClassFormatError( );     class_index = in.readChar( );    name_and_type_index = in.readChar( );   }   /** Used during outputserialization by ClassFile only. */   void serialize(DataOutputStreamout)     throws IOException{     out.writeByte(tag);    out.writeChar(class_index);     out.writeChar(name_and_type_index);  } }A23. CONSTANT_NameAndType_info.javaConvience class for representing CONSTANT_NameAndType_info structureswithin ClassFiles.

import java.io.*; import java.lang.*; /** NameAndType subtype of aconstant pool entry.  */ public final class CONSTANT_NameAndType_infoextends cp_info{  /** The index to the Utf8 that contains the name. */ public int name_index;  /** The index fo the Utf8 that constains thesignature. */  public int descriptor_index;  publicCONSTANT_NameAndType_info(int name_index,  int descriptor_index) {   tag= 12;   this.name_index = name_index;   this.descriptor_index =descriptor_index;  }  /** Used during input serialization by ClassFileonly. */  CONSTANT_NameAndType_info(ClassFile cf, DataInputStream in)  throws IOException{   super(cf, in);   if (tag != 12)    throw newClassFormatError( );   name_index = in.readChar( );   descriptor_index =in.readChar( );  }  /** Used during output serialization by ClassFileonly. */  void serialize(DataOutputStream out)   throws IOException{  out.writeByte(tag);   out.writeChar(name_index);  out.writeChar(descriptor_index);  } }A24. CONSTANT_String_info.javaConvience class for representing CONSTANT_String_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** String subtype of a constantpool entry.  */ public final class CONSTANT_String_info extends cp_info{ /** The index to the actual value of the string. */  public intstring_index;  public CONSTANT_String_info(int value) {   tag = 8;  string_index = value;  }  /** ONLY TO BE USED BY CLASSFILE! */  publicCONSTANT_String_info(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);   if (tag != 8)    throw newClassFormatError( );   string_index = in.readChar( );  }  /** Outputserialization, ONLY TO BE USED BY CLASSFILE! */  public voidserialize(DataOutputStream out)   throws IOException{  out.writeByte(tag);   out.writeChar(string_index);  } }A25. CONSTANT_UTf8_info.javaConvience class for representing CONSTANT_Utf8_info structures withinClassFiles.

import java.io.*; import java.lang.*; /** Utf8 subtype of a constantpool entry.  *  We internally represent the Utf8 info byte array  *  asa String.  */ public final class CONSTANT_Utf8_info extends cp_info{ /** Length of the byte array. */  public int length;  /** The actualbytes, represented by a String. */  public String bytes;  /** Thisconstructor should be used for the purpose   *  of part creation. Itdoes not set the parent   *  ClassFile reference.   */  publicCONSTANT_Utf8_info(String s) {   tag = 1;   length = s.length( );  bytes = s;  }  /** Used during input serialization by ClassFileonly. */  public CONSTANT_Utf8_info(ClassFile cf, DataInputStream in)  throws IOException{   super(cf, in);   if (tag != 1)    throw newClassFormatError( );   length = in.readChar( );   byte[ ] b = newbyte[length];   in.read(b, 0, length);   // WARNING: String constructoris deprecated.   bytes = new String(b, 0, length);  }  /** Used duringoutput serialization by ClassFile only. */  public voidserialize(DataOutputStream out)   throws IOException{  out.writeByte(tag);   out.writeChar(length);   // WARNING: Handling ofString coversion here might be   problematic.   out.writeBytes(bytes); }  public String toString( ){   return bytes;  } }A26. ConstantValue_attribute.javaConvience class for representing ConstantValue_attribute structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** Attribute that allows forinitialization of static variables in  *  classes. This attribute willonly reside in a field_info struct.  */ public final classConstantValue_attribute extends attribute_info{  public intconstantvalue_index;  public ConstantValue_attribute(ClassFile cf, intani, int al, int cvi){   super(cf);   attribute_name_index = ani;  attribute_length = al;   constantvalue_index = cvi;  }  publicConstantValue_attribute(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);   constantvalue_index = in.readChar( );  } public void serialize(DataOutputStream out)   throws IOException{  attribute_length = 2;   super.serialize(out);  out.writeChar(constantvalue_index);  } }A27. cp_info.javaConvience class for representing cp_info structures within ClassFiles.

import java.lang.*; import java.io.*; /** Represents the commoninterface of all constant pool parts  *  that all specific constant poolitems must inherit from.  *  */ public abstract class cp_info{  /** Thetype tag that signifies what kind of constant pool   *  item it is */ public int tag;  /** Used for serialization of the object back into abytestream. */  abstract void serialize(DataOutputStream out) throwsIOException;  /** Default constructor. Simply does nothing. */  publiccp_info( ) { }  /** Constructor simply takes in the ClassFile as areference to   *  it's parent   */  public cp_info(ClassFile cf) { } /** Used during input serialization by ClassFile only. */ cp_info(ClassFile cf, DataInputStream in)   throws IOException{   tag =in.readUnsignedByte( );  } }A28. Deprecated_attribute.javaConvience class for representing Depracated_attribute structures withinClassFiles.

import java.lang.*; import java.io.*; /** A fix attributed that can belocated either in the ClassFile,  *  field_info or the method_infoattribute. Mark deprecated to  *  indicate that the method, class orfield has been superceded.  */ public final class Deprecated_attributeextends attribute_info{  public Deprecated_attribute(ClassFile cf, intani, int al){   super(cf);   attribute_name_index = ani;  attribute_length = al;  }  /** Used during input serialization byClassFile only. */  Deprecated_attribute(ClassFile cf, DataInputStreamin)   throws IOException{   super(cf, in);  } }A29. Exceptions_attribute.javaConvience class for representing Exceptions_attribute structures withinClassFiles.

import java.lang.*; import java.io.*; /** This is the struct where theexceptions table are located.  *  <br><br>  *  This attribute can onlyappear once in a method_info struct.  */ public final classExceptions_attribute extends attribute_info{  public intnumber_of_exceptions;  public int[ ] exception_index_table;  publicExceptions_attribute(ClassFile cf, int ani, int al, int noe,        int[] eit){   super(cf);   attribute_name_index = ani;   attribute_length =al;   number_of_exceptions = noe;   exception_index_table = eit;  }  /**Used during input serialization by ClassFile only. */ Exceptions_attribute(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);   number_of_exceptions = in.readChar( );  exception_index_table = new int [number_of_exceptions];   for (inti=0; i<number_of_exceptions; i++)    exception_index_table[i] =in.readChar( );  }  /** Used during output serialization by ClassFileonly. */  public void serialize(DataOutputStream out)   throwsIOException{   attribute_length = 2 + (number_of_exceptions*2);  super.serialize(out);   out.writeChar(number_of_exceptions);   for(int i=0; i<number_of_exceptions; i++)   out.writeChar(exception_index_table[i]);  } }A30. field_info.javaConvience class for representing field_info structures withinClassFiles.

import java.lang.*; import java.io.*; /**  Represents the field_infostructure as specified in the JVM specification.  */ public final classfield_info{  public int access_flags;  public int name_index;  publicint descriptor_index;  public int attributes_count;  publicattribute_info[ ] attributes;  /** Convenience constructor. */  publicfield_info(ClassFile cf, int flags, int ni, int di){   access_flags =flags;   name_index = ni;   descriptor_index = di;   attributes_count =0;   attributes = new attribute_info[0];  }  /** Constructor called onlyduring the serialization process.   *  <br><br>   *  This isintentionally left as package protected as we   *  should not normallycall this constructor directly.   *  <br><br>   *  Warning: the handlingof len is not correct (after String s =...)   */  field_info(ClassFilecf, DataInputStream in)   throws IOException{   access_flags =in.readChar( );   name_index = in.readChar( );   descriptor_index =in.readChar( );   attributes_count = in.readChar( );   attributes = newattribute_info[attributes_count];   for (int i=0; i<attributes_count;i++){    in.mark(2);    String s = cf.constant_pool[in.readChar()].toString( );    in.reset( );    if (s.equals(“ConstantValue”))    attributes[i] = new ConstantValue_attribute(cf, in);    else if(s.equals(“Synthetic”))     attributes[i] = new Synthetic_attribute(cf,in);    else if (s.equals(“Deprecated”))     attributes[i] = newDeprecated_attribute(cf, in);    else     attributes[i] = newattribute_info.Unknown(cf, in);   }  }  /** To serialize the contentsinto the output format.   */  public void serialize(DataOutputStreamout)   throws IOException{   out.writeChar(access_flags);  out.writeChar(name_index);   out.writeChar(descriptor_index);  out.writeChar(attributes_count);   for (int i=0; i<attributes_count;i++)    attributes[i].serialize(out);  } }A31. InnerClasses_attribute.javaConvience class for representing InnerClasses_attribute structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** A variable length structurethat contains information about an  *  inner class of this class.  */public final class InnerClasses_attribute extends attribute_info{ public int number_of_classes;  public classes[ ] classes;  public finalstatic class classes{   int inner_class_info_index;   intouter_class_info_index;   int inner_name_index;   intinner_class_access_flags;  }  public InnerClasses_attribute(ClassFilecf, int ani, int al,        int noc, classes[ ] c){   super(cf);  attribute_name_index = ani;   attribute_length = al;  number_of_classes = noc;   classes = c;  }  /** Used during inputserialization by ClassFile only. */  InnerClasses_attribute(ClassFilecf, DataInputStream in)   throws IOException{   super(cf, in);  number_of_classes = in.readChar( );   classes = newInnerClasses_attribute.classes[number_of_classes];   for (int i=0;i<number_of_classes; i++){    classes[i] = new classes( );   classes[i].inner_class_info_index = in.readChar( );   classes[i].outer_class_info_index = in.readChar( );   classes[i].inner_name_index = in.readChar( );   classes[i].inner_class_access_flags = in.readChar( );   }  }  /**Used during output serialization by ClassFile only. */  public voidserialize(DataOutputStream out)   throws IOException{   attribute_length= 2 + (number_of_classes * 8);   super.serialize(out);  out.writeChar(number_of_classes);   for (int i=0; i<number_of_classes;i++){    out.writeChar(classes[i].inner_class_info_index);   out.writeChar(classes[i].outer_class_info_index);   out.writeChar(classes[i].inner_name_index);   out.writeChar(classes[i].inner_class_access_flags);   }  } }A32. LineNumberTable_attribute.javaConvience class for representing LineNumberTable_attribute structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** Determines which line of thebinary code relates to the  *  corresponding source code.  */ publicfinal class LineNumberTable_attribute extends attribute_info{  publicint line_number_table_length;  public line_number_table[ ]line_number_table;  public final static class line_number_table{   intstart_pc;   int line_number;  }  publicLineNumberTable_attribute(ClassFile cf, int ani, int al, int lntl,       line_number_table[ ] lnt){   super(cf);   attribute_name_index =ani;   attribute_length = al;   line_number_table_length = lntl;  line_number_table = lnt;  }  /** Used during input serialization byClassFile only. */  LineNumberTable_attribute(ClassFile cf,DataInputStream in)   throws IOException{   super(cf, in);  line_number_table_length = in.readChar( );   line_number_table = newLineNumberTable_attribute.line_number_table[line_number_table_length];  for (int i=0; i<line_number_table_length; i++){   line_number_table[i] = new line_number_table( );   line_number_table[i].start_pc = in.readChar( );   line_number_table[i].line_number = in.readChar( );   }  }  /** Usedduring output serialization by ClassFile only. */  voidserialize(DataOutputStream out)   throws IOException{   attribute_length= 2 + (line_number_table_length * 4);   super.serialize(out);  out.writeChar(line_number_table_length);   for (int i=0;i<line_number_table_length; i++){   out.writeChar(line_number_table[i].start_pc);   out.writeChar(line_number_table[i].line_number);   }  } }A33. LocalVariableTable_attribute.javaConvience class for representing LocalVariableTable_attribute structureswithin ClassFiles.

import java.lang.*; import java.io.*; /** Used by debugger to find outhow the source file line number is linked  *  to the binary code. It hasmany to one correspondence and is found in  *  the Code_attribute.  */public final class LocalVariableTable_attribute extends attribute_info{ public int local_variable_table_length;  public local_variable_table[ ]local_variable_table;  public final static class local_variable_table{  int start_pc;   int length;   int name_index;   int descriptor_index;  int index;  }  public LocalVariableTable_attribute(ClassFile cf, intani, int al,        int lvtl, local_variable_table[ ] lvt){   super(cf);  attribute_name_index = ani;   attribute_length = al;  local_variable_table_length = lvtl;   local_variable_table = lvt;  } /** Used during input serialization by ClassFile only. */ LocalVariableTable_attribute(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);   local_variable_table_length =in.readChar( );   local_variable_table = newLocalVariableTable_attribute.local_variable_table[local_variable_table_length];  for (int i=0; i<local_variable_table_length; i++){   local_variable_table[i] = new local_variable_table( );   local_variable_table[i].start_pc = in.readChar( );   local_variable_table[i].length = in.readChar( );   local_variable_table[i].name_index = in.readChar( );   local_variable_table[i].descriptor_index = in.readChar( );   local_variable_table[i].index = in.readChar( );   }  }  /** Usedduring output serialization by ClassFile only. */  voidserialize(DataOutputStream out)   throws IOException{   attribute_length= 2 + (local_variable_table_length * 10);   super.serialize(out);  out.writeChar(local_variable_table_length);   for (int i=0;i<local_variable_table_length; i++){   out.writeChar(local_variable_table[i].start_pc);   out.writeChar(local_variable_table[i].length);   out.writeChar(local_variable_table[i].name_index);   out.writeChar(local_variable_table[i].descriptor_index);   out.writeChar(local_variable_table[i].index);   }  } }A34. method_info.javaConvience class for representing method_info structures withinClassFiles.

import java.lang.*; import java.io.*; /** This follows the method_infoin the JVM specification.  */ public final class method_info {  publicint access_flags;  public int name_index;  public int descriptor_index; public int attributes_count;  public attribute_info[ ] attributes;  /**Constructor. Creates a method_info, initializes it with   *  the flagsset, and the name and descriptor indexes given.   *  A new uninitializedcode attribute is also created, and stored   *  in the <i>code</i>variable.*/  public method_info(ClassFile cf, int flags, int ni, int di,      int ac, attribute_info[ ] a) {   access_flags = flags;  name_index = ni;   descriptor_index = di;   attributes_count = ac;  attributes = a;  }  /** This method creates a method_info from thecurrent pointer in the   *  data stream. Only called by during theserialization of a complete   *  ClassFile from a bytestream, notnormally invoked directly.   */  method_info(ClassFile cf,DataInputStream in)   throws IOException{   access_flags = in.readChar();   name_index = in.readChar( );   descriptor_index = in.readChar( );  attributes_count = in.readChar( );   attributes = newattribute_info[attributes_count];   for (int i=0; i<attributes_count;i++){    in.mark(2);    String s = cf.constant_pool[in.readChar()].toString( );    in.reset( );    if (s.equals(“Code”))    attributes[i] = new Code_attribute(cf, in);    else if(s.equals(“Exceptions”))     attributes[i] = newExceptions_attribute(cf, in);    else if (s.equals(“Synthetic”))    attributes[i] = new Synthetic_attribute(cf, in);    else if(s.equals(“Deprecated”))     attributes[i] = newDeprecated_attribute(cf, in);    else     attributes[i] = newattribute_info.Unknown(cf, in);   }  }  /** Output serialization of themethod_info to a byte array.   *  Not normally invoked directly.   */ public void serialize(DataOutputStream out)   throws IOException{  out.writeChar(access_flags);   out.writeChar(name_index);  out.writeChar(descriptor_index);   out.writeChar(attributes_count);  for (int i=0; i<attributes_count; i++)   attributes[i].serialize(out);  } }A35. SourceFile_attribute.javaConvience class for representing SourceFile_attribute structures withinClassFiles.

import java.lang.*; import java.io.*; /** A SourceFile attribute is anoptional fixed_length attribute in  *  the attributes table. Onlylocated in the ClassFile struct only  *  once.  */ public final classSourceFile_attribute extends attribute_info{  public intsourcefile_index;  public SourceFile_attribute(ClassFile cf, int ani,int al, int sfi){   super(cf);   attribute_name_index = ani;  attribute_length = al;   sourcefile_index = sfi;  }  /** Used duringinput serialization by ClassFile only. */ SourceFile_attribute(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);   sourcefile_index = in.readChar( );  } /** Used during output serialization by ClassFile only. */  voidserialize(DataOutputStream out)   throws IOException{   attribute_length= 2;   super.serialize(out);   out.writeChar(sourcefile_index);  } }A36. Synthetic_attribute.javaConvience class for representing Synthetic_attribute structures withinClassFiles.

import java.lang.*; import java.io.*; /** A synthetic attributeindicates that this class does not have  *  a generated code source. Itis likely to imply that the code  *  is generated by machine meansrather than coded directly. This  *  attribute can appear in theclassfile, method_info or field_info.  *  It is fixed length.  */ publicfinal class Synthetic_attribute extends attribute_info{  publicSynthetic_attribute(ClassFile cf, int ani, int al){   super(cf);  attribute_name_index = ani;   attribute_length = al;  }  /** Usedduring output serialization by ClassFile only. */ Synthetic_attribute(ClassFile cf, DataInputStream in)   throwsIOException{   super(cf, in);  } }

ANNEXURE B B1

Method <clinit>  0 new #2 <Class test>  3 dup  4 invokespecial #3<Method test( )>  7 putstatic #4 <Field test thisTest>  10 return

B2

Method <clinit>   0 invokestatic #3 <Method boolean isAlreadyLoaded( )>  3 ifeq 7   6 return   7 new #5 <Class test>  10 dup  11 invokespecial#6 <Method test( )>  14 putstatic #7 <Field test thisTest>  17 return

B3

Method <init>   0 aload_0   1 invokespecial #1 <Method java.lang.Object()>   4 aload_0   5 invokestatic #2 <Method long currentTimeMillis( )>  8 putfield #3 <Field long timestamp>  11 return

B4

Method <init>   0 aload_0   1 invokespecial #1 <Method java.lang.Object()>   4 invokestatic #2 <Method boolean isAlreadyLoaded( )>   7 ifeq 11 10 return  11 aload_0  12 invokestatic #4 <Method longcurrentTimeMillis( )>  15 putfield #5 <Field long timestamp>  18 return

B5

Method <clinit>   0 ldc #2 <String “test”>   2 invokestatic #3 <Methodboolean isAlreadyLoaded(java.lang.String)>   5 ifeq 9   8 return   9 new#5 <Class test>  12 dup  13 invokespecial #6 <Method test( )>  16putstatic #7 <Field test thisTest>  19 return

B6

Method <init>   0 aload_0   1 invokespecial #1 <Method java.lang.Object()>   4 aload_0   5 invokestatic #2 <Method booleanisAlreadyLoaded(java.lang.Object)>   8 ifeq 12  11 return  12 aload_0 13 invokestatic #4 <Method long currentTimeMillis( )>  16 putfield #5<Field long timestamp>  19 return

ANNEXURE B7

This excerpt is the source-code of InitClient, which queries an“initialisation server” for the initialisation status of the relevantclass or object.

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class InitClient{ /** Protocol specific values. */public final static int CLOSE = −1; public final static int NACK = 0;public final static int ACK = 1; public final static intINITIALIZE_CLASS = 10; public final static int INITIALIZE_OBJECT = 20;/** InitServer network values. */ public final static StringserverAddress = System.getProperty(“InitServer_network_address”); publicfinal static int serverPort =Integer.parseInt(System.getProperty(“InitServer_network_port”)); /**Table of global ID's for local objects. (hashcode-to-globalIDmappings) */ public final static Hashtable hashCodeToGlobalID = newHashtable( ); /** Called when a object is being initialized. */ publicstatic boolean isAlreadyLoaded(Object o){ // First of all, we need toresolve the globalID // for object ‘o’. To do this we use thehashCodeToGlobalID // table. int globalID = ((Integer)hashCodeToGlobalID.get(o)).intValue( ); try{ // Next, we want to connectto the InitServer, which will inform us // of the initialization statusof this object. Socket socket = new Socket(serverAddress, serverPort);DataOutputStream out = new. DataOutputStream(socket.getOutputStream( ));DataInputStream in = new DataInputStream(socket.getInputStream( )); //Ok, now send the serialized request to the InitServer.out.writeInt(INITIALIZE_OBJECT); out.writeInt(globalID); out.flush( );// Now wait for the reply. int status = in.readInt( ); // This is ablocking call. So we // will wait until the remote side // sendssomething. if (status == NACK){ throw new AssertionError( “Negativeacknowledgement. Request failed.”); }else if (status != ACK){ throw newAssertionError(“Unknown acknowledgement: ” + status + “. Requestfailed.”); } // Next, read in a 32bit argument which is the count ofprevious // initializations. int count = in.readInt( ); // If the countis equal to 0, then this is the first // initialization, and henceisAlreadyLoaded should be false. // If however, the count is greaterthan 0, then this is already // initialized, and thus isAlreadyLoadedshould be true. boolean isAlreadyLoaded = (count == 0 ? false : true);// Close down the connection. out.writeInt(CLOSE); out.flush( );out.close( ); in.close( ); socket.close( ); // Make sure to close thesocket. // Return the value of the isAlreadyLoaded variable. returnisAlreadyLoaded; }catch (IOException e){ throw newAssertionError(“Exception: ” + e.toString( )); } } /** Called when aclass is being initialized. */ public static booleanisAlreadyLoaded(String name){ try{ // First of all, we want to connectto the InitServer, which will // inform us of the initialization statusof this class. Socket socket = new Socket(serverAddress, serverPort);DataOutputStream out = new DataOutputStream(socket.getOutputStream( ));DataInputStream in = new DataInputStream(socket.getInputStream( )); //Ok, now send the serialized request to the InitServer.out.writeInt(INITIALIZE_CLASS); out.writeInt(name.length( )); // A 32bitlength argument of // the String name. out.write(name.getBytes( ), 0,name.length( )); // The byte- // encoded // String name. out.flush( );// Now wait for the reply. int status = in.readInt( ); // This is ablocking call. So we // will wait until the remote side // sendssomething. if (status == NACK){ throw new AssertionError( “Negativeacknowledgement. Request failed.”); }else if (status != ACK){ throw newAssertionError(“Unknown acknowledgement: ” + status + “. Requestfailed.”); } // Next, read in a 32bit argument which is the count of the// previous intializations. int count = in.readInt( ); // If the countis equal to 0, then this is the first // initialization, and henceisAlreadyLoaded should be false. // If however, the count is greaterthan 0, then this is already // loaded, and thus isAlreadyLoaded shouldbe true. boolean isAlreadyLoaded = (count == 0 ? false : true); // Closedown the connection. out.writeInt(CLOSE); out.flush( ); out.close( );in.close( ); socket.close( ); // Make sure to close the socket. //Return the value of the isAlreadyLoaded variable. returnisAlreadyLoaded; }catch (IOException e){ throw newAssertionError(“Exception: ” + e.toString( )); } } }

ANNEXURE B8

This excerpt is the source-code of InitServer, which receives aninitialisation status query by InitClient and in response returns thecorresponding status.

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class InitServer implements Runnable{  /** Protocolspecific values */  public final static int CLOSE = −1;  public finalstatic int NACK = 0;  public final static int ACK = 1;  public finalstatic int INITIALIZE_CLASS = 10;  public final static intINITIALIZE_OBJECT= 20;  /** InitServer network values. */  public finalstatic int serverPort = 20001;  /** Table of initialization records. */ public final static Hashtable initializations = new Hashtable( );  /**Private input/output objects. */  private Socket socket = null;  privateDataOutputStream outputStream;  private DataInputStream inputStream; private String address;  public static void main(String[ ] s)  throwsException{  System.out.println(“InitServer_network_address=” +  InetAddress.getLocalHost( ).getHostAddress( )); System.out.println(“InitServer_network_port=” + serverPort);  // Createa serversocket to accept incoming initialization operation  //connections.  ServerSocket serverSocket = new ServerSocket(serverPort); while (!Thread.interrupted( )){   // Block until an incominginitialization operation connection.   Socket socket =serverSocket.accept( );   // Create a new instance of InitServer tomanage this   // initialization operation connection.   new Thread(newInitServer(socket)).start( );  } } /** Constructor. Initialize this newInitServer instance with necessary   resources for operation. */ publicInitServer(Socket s){  socket = s;  try{   outputStream = newDataOutputStream(s.getOutputStream( ));   inputStream = newDataInputStream(s.getInputStream( ));   address = s.getInetAddress().getHostAddress( );  }catch (IOException e){   throw newAssertionError(“Exception: ” + e.toString( ));  } } /** Main code body.Decode incoming initialization operation requests and   executeaccordingly. */ public void run( ){  try{   // All commands areimplemented as 32bit integers.   // Legal commands are listed in the“protocol specific values”   // fields above.   int command =inputStream.readInt( );   // Continue processing commands until a CLOSEoperation.   while (command != CLOSE){    if (command == // This is an   INITIALIZE_CLASS){ // INITIALIZE_CLASS // operation.     // Read in a32bit length field ‘l’, and a String name for     // this class oflength ‘l’.     int length = inputStream.readInt( );     byte[ ] b = newbyte[length];     inputStream.read(b, 0, b.length);     String className= new String(b, 0, length);     // Synchronize on the initializationstable in order to     // ensure thread-safety.     synchronized(initializations){      // Locate the previous initializations entry forthis      // class, if any.      Integer entry = (Integer)initializations.get(className);     if (entry == null){ // This is anunknown class so // update the table with a // corresponding entry.     initializations.put(className, new Integer(1));      // Send apositive acknowledgement to InitClient,      // together with the countof previous initializations      // of this class - which in this caseof an unknown      // class must be 0.      outputStream.writeInt(ACK);     outputStream.writeInt(0);      outputStream.flush( );     }else{ //This is a known class, so update // the count of initializations.     initializations.put(className,       new Integer(entry.intValue() + 1));      // Send a positive acknowledgement to InitClient,      //together with the count of previous initializtions      // of thisclass - which in this case of a known class      // must be the value of“entry.intValue( )”.      outputStream.writeInt(ACK);     outputStream.writeInt(entry.intValue( ));      outputStream.flush();     }    }   }else if (command == // This is an   INITIALIZE_OBJECT){// INITIALIZE_OBJECT // operation.    // Read in the globalID of theobject to be initialized.    int globalID = inputStream.readInt( );   // Synchronize on the initializations table in order to    // ensurethread-safety.    synchronized (initializations){     // Locate theprevious initializations entry for this     // object, if any.    Integer entry = (Integer) initializations.get(      newInteger(globalID));     if (entry == null){ // This is an unknown objectso // update the table with a // corresponding entry.     initializations.put(new Integer(globalID),       new Integer(1));     // Send a positive acknowledgement to InitClient,      // togetherwith the count of previous initializations      // of this object -which in this case of an unknown      // object must be 0.     outputStream.writeInt(ACK);      outputStream.writeInt(0);     outputStream.flush( );     }else{ // This is a known object soupdate the // count of initializations.        initializations.put(newInteger(globalID),         new Integer(entry.intValue( ) + 1));       // Send a positive acknowledgement to InitClient,        //together with the count of previous initializations        // of thisobject - which in this case of a known        // object must be value“entry.intValue( )”.        outputStream.writeInt(ACK);       outputStream.writeInt(entry.intValue( ));       outputStream.flush( );       }      }     }else{    // Unknowncommand.      throw new AssertionError(       “Unknown command.Operation failed.”);     }     // Read in the next command.     command= inputStream.readInt( );    }   }catch (Exception e){    throw newAssertionError(“Exception: ” + e.toString( ));   }finally{    try{    // Closing down. Cleanup this connection.     outputStream.flush( );    outputStream.close( );     inputStream.close( );     socket.close();    }catch (Throwable t){     t.printStackTrace( );    }    // Garbagethese references.    outputStream = null;    inputStream = null;   socket = null;   }  } }

ANNEXURE B9

This excerpt is the source-code of the example application used in thebefore/after examples of Annexure B

import java.lang.*; public class example{  /** Shared static field. */ public static example currentExample;  /** Shared instance field. */ public long timestamp;  /** Static intializer. (clinit) */  static{  currentExample = new example( );  }  /** Instance intializer (init) */ public example( ){   timestamp = System.currentTimeMillis( );  } }

ANNEXURE B10

InitLoader.javaThis excerpt is the source-code of InitLoader, which modifies anapplication as it is being loaded.

import java.lang.*; import java.io.*; import java.net.*; public classInitLoader extends URLClassLoader{  public InitLoader(URL[ ] urls){  super(urls);  }  protected Class findClass(String name)  throwsClassNotFoundException{   ClassFile cf = null;   try{   BufferedInputStream in = new    BufferedInputStream(findResource(name.replace(‘.’,    ‘/’).concat(“.class”)).openStream( ));    cf = new ClassFile(in);  }catch (Exception e) {throw new ClassNotFoundException(e.toString());}   for (int i=0; i<cf.methods_count; i++){    // Find the <clinit>method_info struct.    String methodName = cf.constant_pool[    cf.methods[i].name_index].toString( );    if(!methodName.equals(“<clinit>”)){     continue;    }    // Now find theCode_attribute for the <clinit> method.    for (int j=0;j<cf.methods[i].attributes_count; j++){     if(!(cf.methods[i].attributes[j] instanceof Code_attribute))     continue;     Code_attribute ca = (Code_attribute)cf.methods[i].attributes[j];     // First, shift the code[ ] down by 4instructions.     byte[ ][ ] code2 = new byte[ca.code.length+4][ ];    System.arraycopy(ca.code, 0, code2, 4, ca.code.length);     ca.code= code2;     // Then enlarge the constant_pool by 7 items.     cp_info[] cpi = new cp_info[cf.constant_pool.length+7];    System.arraycopy(cf.constant_pool, 0, cpi, 0,     cf.constant_pool.length);     cf.constant_pool = cpi;    cf.constant_pool_count += 7;     // Now add the constant pool itemsfor these instructions, starting     // with String.    CONSTANT_String_info csi = new CONSTANT_String_info(   ((CONSTANT_Class_info)cf.constant_pool[cf.this_class]).name_index);    cf.constant_pool[cf.constant_pool.length−7] = csi;     // Now addthe UTF for class.     CONSTANT_Utf8_info u1 = newCONSTANT_Utf8_info(“InitClient”);    cf.constant_pool[cf.constant_pool.length−6] = u1;     // Now add theCLASS for the previous UTF.     CONSTANT_Class_info c1 =      newCONSTANT_Class_info(cf.constant_pool.length−6);    cf.constant_pool[cf.constant_pool.length−5] = c1;     // Next addthe first UTF for NameAndType.     u1 = newCONSTANT_Utf8_info(“isAlreadyLoaded”);    cf.constant_pool[cf.constant_pool.length−4] = u1;     // Next addthe second UTF for NameAndType.     u1 = newCONSTANT_Utf8_info(“(Ljava/lang/String;)Z”);    cf.constant_pool[cf.constant_pool.length−3] = u1;     // Next addthe NameAndType for the previous two UTFs.     CONSTANT_NameAndType_infon1 = new CONSTANT_NameAndType_info(      cf.constant_pool.length−4,cf.constant_pool.length−3);    cf.constant_pool[cf.constant_pool.length−2] = n1;     // Next addthe Methodref for the previous CLASS and NameAndType.    CONSTANT_Methodref_info m1 = new CONSTANT_Methodref_info(     cf.constant_pool.length−5, cf.constant_pool.length−2);    cf.constant_pool[cf.constant_pool.length−1] = m1;     // Now withthat done, add the instructions into the code, starting     // with LDC.    ca.code[0] = new byte[3];     ca.code[0][0] = (byte) 19;    ca.code[0][1] = (byte) (((cf.constant_pool.length−7) >> 8) & 0xff);    ca.code[0][2] = (byte) ((cf.constant_pool.length−7) & 0xff);     //Now Add the INVOKESTATIC instruction.     ca.code[1]= new byte[3];    ca.code[1][0] = (byte) 184;     ca.code[1][1] = (byte)(((cf.constant_pool.length−1) >> 8) & 0xff);     ca.code[1][2] = (byte)((cf.constant_pool.length−1) & 0xff);     // Next add the IFEQinstruction.     ca.code[2] = new byte[3];     ca.code[2][0] = (byte)153;     ca.code[2][1] = (byte) ((4 >> 8) & 0xff);     ca.code[2][2] =(byte) (4 & 0xff);     // Finally, add the RETURN instruction.    ca.code[3] = new byte[1];     ca.code[3][0] = (byte) 177;     //Lastly, increment the CODE_LENGTH and ATTRIBUTE_LENGTH values.    ca.code_length += 10;     ca.attribute_length += 10;    }   }   try{   ByteArrayOutputStream out = new ByteArrayOutputStream( );   cf.serialize(out);    byte[ ] b = out.toByteArray( );    returndefineClass(name, b, 0, b.length);   }catch (Exception e){  e.printStackTrace( );    throw new ClassNotFoundException(name);   } } }

ANNEXURE C C1. Typical Prior Art Finalization for a Single Machine

Method finalize( ) 0 getstatic #9 <Field java.io.PrintStream out> 3 ldc#24 <String “Deleted...”> 5 invokevirtual #16 <Method voidprintln(java.lang.String)> 8 return

C2. Preferred Finalization for Multiple Machines

Method finalize( ) 0 invokestatic #3 <Method boolean isLastReference( )>3 ifne 7 6 return 7 getstatic #9 <Field java.io.PrintStream out> 10 ldc#24 <String “Deleted...”> 12 invokevirtual #16 <Method voidprintln(java.lang.String)> 15 return

C3. Preferred Finalization for Multiple Machines (Alternative)

Method finalize( ) 0 aload — 0 1 invokestatic #3 <Method booleanisLastReference(java.lang.Object)> 4 ifne 8 7 return 8 getstatic #9<Field java.io.PrintStream out> 11 ldc #24 <String “Deleted...”> 13invokevirtual #16 <Method void println(java.lang.String)> 16 return

ANNEXURE C4

import java.lang.*; public class example{  /** Finalize method. */ protected void finalize( ) throws Throwable{   // “Deleted...” isprinted out when this object is garbaged.  System.out.println(“Deleted...”);  } }

ANNEXURE C5

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class FinalClient{  /** Protocol specific values. */ public final static int CLOSE = −1;  public final static int NACK = 0; public final static int ACK = 1;  public final static intFINALIZE_OBJECT = 10;  /** FinalServer network values. */  public finalstatic String serverAddress =  System.getProperty(“FinalServer_network_address”);  public finalstatic int serverPort =  Integer.parseInt(System.getProperty(“FinalServer_network_port”));  /**Table of global ID's for local objects. (hashcode-to-globalID  mappings) */  public final static Hashtable hashCodeToGlobalID = newHashtable( );  /** Called when a object is being finalized. */  publicstatic boolean isLastReference(Object o){   // First of all, we need toresolve the globalID for object ‘o’.   // To do this we use thehashCodeToGlobalID table.   int globalID = ((Integer)hashCodeToGlobalID.get(o)).intValue( );   try{    // Next, we want toconnect to the FinalServer, which will inform    // us of thefinalization status of this object.    Socket socket = newSocket(serverAddress, serverPort);    DataOutputStream out =     newDataOutputStream(socket.getOutputStream( ));    DataInputStream in =   new DataInputStream(socket.getInputStream( ));    // Ok, now send theserialized request to the FinalServer.    out.writeInt(FINALIZE_OBJECT);   out.writeInt(globalID);    out.flush( );    // Now wait for thereply.    int status = in.readInt( ); // This is a blocking call. So we// will wait until the remote side // sends something.    if (status ==NACK){     throw new AssertionError(      “Negative acknowledgement.Request failed.”);    }else if (status != ACK){     throw newAssertionError(“Unknown acknowledgement: ”      + status + “. Requestfailed.”);    }    // Next, read in a 32bit argument which is the countof the    // remaining finalizations    int count = in.readInt( );    //If the count is equal to 1, then this is the last finalization,    //and hence isLastReference should be true.    // If however, the count isgreater than 1, then this is not the    // last finalization, and thusisLastReference should be false.    boolean isLastReference = (count ==1 ? true : false);    // Close down the connection.   out.writeInt(CLOSE);    out.flush( );    out.close( );    in.close();    socket.close( ); // Make sure to close the socket.    // Returnthe value of the isLastReference variable.    return isLastReference;  }catch (IOException e){    throw new AssertionError(“Exception: ” +e.toString( ));   }  } }

ANNEXURE C6

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class FinalServer implements Runnable{  /** Protocolspecific values */  public final static int CLOSE = −1;  public finalstatic int NACK = 0;  public final static int ACK = 1;  public finalstatic int FINALIZE_OBJECT = 10;  /** FinalServer network values. */ public final static int serverPort = 20001;  /** Table of finalizationrecords. */  public final static Hashtable finalizations = newHashtable( );  /** Private input/output objects. */  private Socketsocket = null;  private DataOutputStream outputStream;  privateDataInputStream inputStream;  private String address;  public staticvoid main(String[ ] s)  throws Exception{  System.out.println(“FinalServer_network_address=”    +InetAddress.getLocalHost( ).getHostAddress( ));  System.out.println(“FinalServer_network_port=” + serverPort);   //Create a serversocket to accept incoming initialization operation   //connections.  ServerSocket serverSocket = new ServerSocket(serverPort); while (!Thread.interrupted( )){   // Block until an incominginitialization operation connection.   Socket socket =serverSocket.accept( );   // Create a new instance of InitServer tomanage this   // initialization operation connection.   new Thread(newFinalServer(socket)).start( );  } } /** Constructor. Initialize this newFinalServer instance with necessary   resources for operation. */ publicFinalServer(Socket s){  socket = s;  try{   outputStream = newDataOutputStream(s.getOutputStream( ));   inputStream = newDataInputStream(s.getInputStream( ));   address = s.getInetAddress().getHostAddress( );  }catch (IOException e){   throw newAssertionError(“Exception: ” + e.toString( ));  } } /** Main code body.Decode incoming finalization operation requests and   executeaccordingly. */ public void run( ){  try{   // All commands areimplemented as 32bit integers.   // Legal commands are listed in the“protocol specific values”   // fields above.   int command =inputStream.readInt( );   // Continue processing commands until a CLOSEoperation.   while (command != CLOSE){    if (command ==   FINALIZE_OBJECT){ // This is a // FINALIZE_OBJECT // operation.    // Read in the globalID of the object to be finalized.     intglobalID = inputStream.readInt( );     // Synchronize on thefinalizations table in order to ensure     // thread-safety.    synchronized (finalizations){      // Locate the previousfinalizations entry for this      // object, if any.      Integer entry= (Integer) finalizations.get(       new Integer(globalID));      if(entry == null){       throw new AssertionError(“Unknown object.”);     }else if (entry.intValue( ) < 1){       throw newAssertionError(“Invalid count.”);      }else if (entry.intValue( ) ==1){ // Count of 1 means // this is the last // reference, hence //remove from table.        finalizations.remove(new Integer(globalID));       // Send a positive acknowledgement to FinalClient,        //together with the count of remaining references -        // which inthis case is 1.        outputStream.writeInt(ACK);       outputStream.writeInt(1);        outputStream.flush( );      }else{ // This is not the last remaining // reference, as count isgreater than 1. // Decrement count by 1.        finalizations.put(newInteger(globalID),         new Integer(entry.intValue( ) − 1));       // Send a positive acknowledgement to FinalClient,        //together with the count of remaining references to        // thisobject - which in this case of must be value        // “entry.intValue()”.        outputStream.writeInt(ACK);       outputStream.writeInt(entry.intValue( ));       outputStream.flush( );       }      }     }else{    // Unknowncommand.      throw new AssertionError(      “Unknown command. Operationfailed.”);     }     // Read in the next command.     command =inputStream.readInt( );    }   }catch (Exception e){    throw newAssertionError(“Exception: ” + e.toString( ));   }finally{    try{    // Closing down. Cleanup this connection.     outputStream.flush( );    outputStream.close( );     inputStream.close( );     socket.close();    }catch (Throwable t){     t.printStackTrace( );    }    // Garbagethese references.    outputStream = null;    inputStream = null;   socket = null;   }  } }

ANNEXURE C7

FinalLoader.javaThis excerpt is the source-code of FinalLoader, which modifies anapplication as it is being loaded.

import java.lang.*; import java.io.*; import java.net.*; public classFinalLoader extends URLClassLoader{  public FinalLoader(URL[ ] urls){  super(urls);  }  protected Class findClass(String name)  throwsClassNotFoundException{   ClassFile cf = null;   try{   BufferedInputStream in =     newBufferedInputStream(findResource(name.replace(‘.’,    ‘/’).concat(“.class”)).openStream( ));    cf = new ClassFile(in);  }catch (Exception e){throw new ClassNotFoundException(e.toString( ));}  for (int i=0; i<cf.methods_count; i++){    // Find the finalizemethod_info struct.    String methodName = cf.constant_pool[    cf.methods[i].name_index].toString( );    if(!methodName.equals(“finalize”)){     continue;    }    // Now find theCode_attribute for the finalize method.    for (int j=0;j<cf.methods[i].attributes_count; j++){     if(!(cf.methods[i].attributes[j] instanceof Code_attribute))     continue;     Code_attribute ca = (Code_attribute)cf.methods[i].attributes[j];     // First, shift the code[ ] down by 4instructions.     byte[ ][ ] code2 = new byte[ca.code.length+4][ ];    System.arraycopy(ca.code, 0, code2, 4, ca.code.length);     ca.code= code2;     // Then enlarge the constant_pool by 6 items.     cp_info[] cpi = new cp_info[cf.constant_pool.length+6];    System.arraycopy(cf.constant_pool, 0, cpi, 0,     cf.constant_pool.length);     cf.constant_pool = cpi;    cf.constant_pool_count += 6;     // Now add the UTF for class.    CONSTANT_Utf8_info ul = new CONSTANT_Utf8_info(“FinalClient”);    cf.constant_pool[cf.constant_pool.length−6] = u1;     // Now add theCLASS for the previous UTF.     CONSTANT_Class_info c1 =      newCONSTANT_Class_info(cf.constant_pool.length−6);    cf.constant_pool[cf.constant_pool.length−5] = c1;     // Next addthe first UTF for NameAndType.     u1 = newCONSTANT_Utf8_info(“isLastReference”);    cf.constant_pool[cf.constant_pool.length−4] = u1;     // Next addthe second UTF for NameAndType.     u1 = newCONSTANT_Utf8_info(“(Ljava/lang/Object;)Z”);    cf.constant_pool[cf.constant_pool.length−3] = u1;     // Next addthe NameAndType for the previous two UTFs.     CONSTANT_NameAndType_infon1 = new CONSTANT_NameAndType_info(      cf.constant_pool.length−4,cf.constant_pool.length−3);    cf.constant_pool[cf.constant_pool.length−2] = n1;     // Next addthe Methodref for the previous CLASS and NameAndType.    CONSTANT_Methodref_info m1 = new CONSTANT_Methodref_info(     cf.constant_pool.length−5, cf.constant_pool.length−2);    cf.constant_pool[cf.constant_pool.length−1] = m1;     // Now withthat done, add the instructions into the code, starting     // with LDC.    ca.code[0] = new byte[1];     ca.code[0][0] = (byte) 42;     // NowAdd the INVOKESTATIC instruction.     ca.code[1] = new byte[3];    ca.code[1][0] = (byte) 184;     ca.code[1][1] = (byte)(((cf.constant_pool.length−1) >> 8) & 0xff);     ca.code[1][2] = (byte)((cf.constant_pool.length−1) & 0xff);     // Next add the IFNEinstruction.     ca.code[2] = new byte[3];     ca.code[2][0] = (byte)154;     ca.code[2][1] = (byte) ((4 >> 8) & 0xff);     ca.code[2][2] =(byte) (4 & 0xff);     // Finally, add the RETURN instruction.    ca.code[3] = new byte[1];     ca.code[3][0] = (byte) 177;     //Lastly, increment the CODE_LENGTH and ATTRIBUTE_LENGTH values.    ca.code_length += 8;     ca.attribute_length += 8;    }   }   try{   ByteArrayOutputStream out = new ByteArrayOutputStream( );   cf.serialize(out);    byte[ ] b = out.toByteArray( );    returndefineClass(name, b, 0, b.length);   }catch (Exception e){   e.printStackTrace( );    throw new ClassNotFoundException(name);   } } }

ANNEXURE D1

Method void run( )  0 getstatic #2 <Field java.lang.Object LOCK>  3 dup 4 astore_1  5 monitorenter  6 getstatic #3 <Field int counter>  9iconst_1   10 iadd   11 putstatic #3 <Field int counter>   14 aload_1  15 monitorexit   16 return

ANNEXURE D2

Method void run( )  0 getstatic #2 <Field java.lang.Object LOCK>  3 dup 4 astore_1  5 dup  6 monitorenter  7 invokestatic #23 <Method voidacquireLock(java.lang.Object)>   10 getstatic #3 <Field int counter>  13 iconst_1   14 iadd   15 putstatic #3 <Field int counter>   18aload_1   19 dup   20 invokestatic #24 <Method voidreleaseLock(java.lang.Object)>   23 monitorexit   24 return

ANNEXURE D3

import java.lang.*; public class example{  /** Shared static field. */ public final static Object LOCK = new Object( );  /** Shared staticfield. */  public static int counter = 0;  /** Example method usingsynchronization. This method serves to   illustrate the use ofsynchronization to implement thread-safe   modification of a sharedmemory location by potentially multiple   threads. */  public void run(){   // First acquire the lock, otherwise any memory writes we do willbe   // prone to race-conditions.   synchronized (LOCK){    // Now thatwe have acquired the lock, we can safely modify    memory    // in athread-safe manner.    counter++;   }  } }

ANNEXURE D4

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class LockClient{  /** Protocol specific values. */ public final static int CLOSE = −1;  public final static int NACK = 0; public final static int ACK = 1;  public final static int ACQUIRE_LOCK= 10;  public final static int RELEASE_LOCK = 20;  /** LockServernetwork values. */  public final static String serverAddress =  System.getProperty(“LockServer_network_address”);  public final staticint serverPort =  Integer.parseInt(System.getProperty(“LockServer_network_port”));  /**Table of global ID's for local objects. (hashcode-to-globalID   mappings) */  public final static Hashtable hashCodeToGlobalID = newHashtable( );  /** Called when an application is to acquire a lock. */ public static void acquireLock(Object o){   // First of all, we need toresolve the globalID for object ‘o’.   // To do this we use thehashCodeToGlobalID table.   int globalID = ((Integer)hashCodeToGlobalID.get(o)).intValue( );   try{    // Next, we want toconnect to the LockServer, which will grant us    // the global lock.   Socket socket = new Socket(serverAddress, serverPort);   DataOutputStream out =     newDataOutputStream(socket.getOutputStream( ));    DataInputStream in = newDataInputStream    (socket.getInputStream( ));    // Ok, now send theserialized request to the lock server.    out.writeInt(ACQUIRE_LOCK);   out.writeInt(globalID);    out.flush( );    // Now wait for thereply.    int status = in.readInt( ); // This is a blocking call. So we// will wait until the remote side // sends something.    if (status ==NACK){     throw new AssertionError(      “Negative acknowledgement.Request failed.”);    }else if (status != ACK){     throw newAssertionError(“Unknown acknowledgement: ”      + status + “. Requestfailed.”);    }    // Close down the connection.    out.writeInt(CLOSE);   out.flush( );    out.close( );    in.close( );    socket.close( );   // Make sure to close the socket.    // This is a goodacknowledgement, thus we can return    now because    // global lock isnow acquired.    return;   }catch (IOException e){    throw newAssertionError(“Exception: ” + e.toString( ));   }  }  /** Called whenan application is to release a lock. */  public static voidreleaseLock(Object o){   // First of all, we need to resolve theglobalID for object ‘o’.   // To do this we use the hashCodeToGlobalIDtable.   int globalID = ((Integer) hashCodeToGlobalID.get(o)).intValue();   try{    // Next, we want to connect to the LockServer, whichrecords us as    // the owner of the global lock for object ‘o’.   Socket socket = new Socket(serverAddress, serverPort);   DataOutputStream out =     newDataOutputStream(socket.getOutputStream( ));    DataInputStream in = newDataInputStream    (socket.getInputStream( ));    // Ok, now send theserialized request to the lock server.    out.writeInt(RELEASE_LOCK);   out.writeInt(globalID);    out.flush( );    // Now wait for thereply.    int status = in.readInt( ); // This is a blocking call. So we// will wait until the remote side // sends something.    if (status ==NACK){     throw new AssertionError(      “Negative acknowledgement.Request failed.”);    }else if (status != ACK){     throw newAssertionError(“Unknown acknowledgement: ”      + status + “. Requestfailed.”);    }    // Close down the connection.    out.writeInt(CLOSE);   out.flush( );    out.close( );    in.close( );    socket.close( );   // Make sure to close the socket.    // This is a goodacknowledgement, return because global lock is    // now released.   return;    }catch (IOException e){     throw newAssertionError(“Exception: ” + e.toString( ));    }   }  }

ANNEXURE D5

import java.lang.*; import java.util.*; import java.net.*; importjava.io.*; public class LockServer implements Runnable{  /** Protocolspecific values */  public final static int CLOSE = −1;  public finalstatic int NACK = 0;  public final static int ACK = 1;  public finalstatic int ACQUIRE_LOCK = 10;  public final static int RELEASE_LOCK =20;  /** LockServer network values. */  public final static intserverPort = 20001;  /** Table of lock records. */  public final staticHashtable locks = new Hashtable( );  /** Linked list of waitingLockManager objects. */  public LockServer next = null;  /** Address ofremote LockClient. */  public final String address;  /** Privateinput/output objects. */  private Socket socket = null;  privateDataOutputStream outputStream;  private DataInputStream inputStream; public static void main(String[ ] s)  throws Exception{  System.out.println(“LockServer_network_address=”    +InetAddress.getLocalHost( ).getHostAddress( ));  System.out.println(“LockServer_network_port=” + serverPort);   //Create a serversocket to accept incoming lock operation   //connections.   ServerSocket serverSocket = new ServerSocket(serverPort);  while (!Thread.interrupted( )){    // Block until an incoming lockoperation connection.    Socket socket = serverSocket.accept( );    //Create a new instance of LockServer to manage this lock    // operationconnection.    new Thread(new LockServer(socket)).start( );   }  } /**Constructor. Initialise this new LockServer instance with necessary  resources for operation. */ public LockServer(Socket s){  socket = s; try{   outputStream = new DataOutputStream(s.getOutputStream( ));  inputStream = new DataInputStream(s.getInputStream( ));   address =s.getInetAddress( ).getHostAddress( );  }catch (IOException e){   thrownew AssertionError(“Exception: ” + e.toString( ));  } } /** Main codebody. Decode incoming lock operation requests and   execute accordingly.*/ public void run( ){  try{   // All commands are implemented as 32bitintegers.   // Legal commands are listed in the “protocol specificvalues”   // fields above.   int command = inputStream.readInt( );   //Continue processing commands until a CLOSE operation.   while (command!= CLOSE){    if (command == ACQUIRE_LOCK){ // This is an //ACQUIRE_LOCK // operation.     // Read in the globalID of the object tobe locked.     int globalID = inputStream.readInt( );     // Synchronizeon the locks table in order to ensure thread-     // safety.    synchronized (locks){      // Check for an existing owner of thislock.      LockServer lock = (LockServer) locks.get(       newInteger(globalID));      if (lock == null){ // No-one presently ownsthis lock, // so acquire it.       locks.put(new Integer(globalID),this);       acquireLock( ); // Signal to the client the // successfulacquisition of this // lock.      }else{ // Already owned. Appendourselves // to end of queue.       // Search for the end of the queue.(Implemented as       // linked-list)       while (lock.next != null){       lock = lock.next;       }       lock.next = this; // Append thislock request at end.      }     }     }else if (command ==    RELEASE_LOCK){ // This is a // RELEASE_LOCK // operation.      //Read in the globalID of the object to be locked.      int globalID =inputStream.readInt( );      // Synchronize on the locks table in orderto ensure thread-      // safety.      synchronized (locks){       //Check to make sure we are the owner of this lock.       LockServer lock= (LockServer) locks.get(        new Integer(globalID));       if (lock== null){        throw new AssertionError(“Unlocked. Release failed.”);      }else if (lock.address != this.address){        throw newAssertionError(“Trying to release a lock “         + ”which this clientdoesn't own. Release “         + ”failed.”);       }       lock =lock.next;       lock.acquireLock( ); // Signal to the client the //successful acquisition of this // lock.       // Shift the linked listof pending acquisitions forward       // by one.       locks.put(newInteger(globalID), lock);       // Clear stale reference.       next =null;      }      releaseLock( ); // Signal to the client the successful// release of this lock.     }else{ // Unknown command.      throw newAssertionError(       “Unknown command. Operation failed.”);     }    // Read in the next command.     command = inputStream.readInt( );   }   }catch (Exception e){    throw new AssertionError(“Exception: ” +e.toString( ));   }finally{    try{     // Closing down. Cleanup thisconnection.     outputStream.flush( );     outputStream.close( );    inputStream.close( );     socket.close( );    }catch (Throwable t){    t.printStackTrace( );    }    // Garbage these references.   outputStream = null;    inputStream = null;    socket = null;   }  } /** Send a positive acknowledgement of an ACQUIRE_LOCK  operation. */ public void acquireLock( ) throws IOException{  outputStream.writeInt(ACK);   outputStream.flush( );  }  /** Send apositive acknowledgement of a RELEASE_LOCK  operation. */  public voidreleaseLock( ) throws IOException{   outputStream.writeInt(ACK);  outputStream.flush( );  } }

ANNEXURE D6

LockLoader.javaThis excerpt is the source-code of LockLoader, which modifies anapplication as it is being loaded.

import java.lang.*; import java.io.*; import java.net.*; public classLockLoader extends URLClassLoader{  public LockLoader(URL[ ] urls){  super(urls);  }  protected Class findClass(String name)  throwsClassNotFoundException{   ClassFile cf = null;   try{   BufferedInputStream in =     newBufferedInputStream(findResource(name.replace(‘.’,    ‘/’).concat(“.class”)).openStream( ));    cf = new ClassFile(in);  }catch (Exception e){throw new ClassNotFoundException(e.toString( ));}  // Class-wide pointers to the enterindex and exitindex.   intenterindex = −1;   int exitindex = −1;   for (int i=0;i<cf.methods_count; i++){    for (int j=0;j<cf.methods[i].attributes_count; j++){     if(!(cf.methods[i].attributes[j] instanceof Code_attribute))     continue;     Code_attribute ca = (Code_attribute)cf.methods[i].attributes[j];     boolean changed = false;     for (intz=0; z<ca.code.length; z++){      if ((ca.code[z][0] & 0xff) == 194){ //Opcode for a // MONITORENTER // instruction.    changed = true;    //Next, realign the code array, making room for the    // insertions.   byte[ ][ ] code2 = new byte[ca.code.length+2][ ];   System.arraycopy(ca.code, 0, code2, 0, z);    code2[z+1] =ca.code[z];    System.arraycopy(ca.code, z+1, code2, z+3,    ca.code.length−(z+1));    ca.code = code2;    // Next, insert theDUP instruction.    ca.code[z] = new byte[1];    ca.code[z][0] = (byte)89;    // Finally, insert the INVOKESTATIC instruction.    if(enterindex == −1){     // This is the first time this class isencourtering the     // acquirelock instruction, so have to add it tothe     // constant pool.     cp_info[ ] cpi = newcp_info[cf.constant_pool.length+6];    System.arraycopy(cf.constant_pool, 0, cpi, 0,     cf.constant_pool.length);     cf.constant_pool = cpi;    cf.constant_pool_count += 6;     CONSTANT_Utf8_info u1 =      newCONSTANT_Utf8_info(“LockClient”);    cf.constant_pool[cf.constant_pool.length−6] = u1;    CONSTANT_Class_info c1 = new CONSTANT_Class_info(     cf.constant_pool_count−6);    cf.constant_pool[cf.constant_pool.length−5] = c1;     u1 = newCONSTANT_Utf8_info(“acquireLock”);    cf.constant_pool[cf.constant_pool.length−4] = u1;     u1 = newCONSTANT_Utf8_info(“(Ljava/lang/Object;)V”);    cf.constant_pool[cf.constant_pool.length−3] = u1;    CONSTANT_NameAndType_info n1 =      new CONSTANT_NameAndType_info(     cf.constant_pool.length−4, cf.constant_pool.length−3);    cf.constant_pool[cf.constant_pool.length−2] = n1;    CONSTANT_Methodref_info m1 = new CONSTANT_Methodref_info(     cf.constant_pool.length−5, cf.constant_pool.length−2);    cf.constant_pool[cf.constant_pool.length−1] = m1;     enterindex =cf.constant_pool.length−1;    }    ca.code[z+2] = new byte[3];   ca.code[z+2][0] = (byte) 184;    ca.code[z+2][1] = (byte)((enterindex >> 8) & 0xff);    ca.code[z+2][2] = (byte) (enterindex &0xff);    // And lastly, increase the CODE_LENGTH and ATTRIBUTE_LENGTH   // values.    ca.code_length += 4;    ca.attribute_length += 4;    z+= 1;   }else if ((ca.code[z][0] & 0xff) == 195){ // Opcode for a //MONITOREXIT // instruction.    changed = true;    // Next, realign thecode array, making room for the    // insertions.    byte[ ][ ] code2 =new byte[ca.code.length+2][ ];    System.arraycopy(ca.code, 0, code2, 0,z);    code2[z+1] = ca.code[z];    System.arraycopy(ca.code, z+1, code2,z+3,     ca.code.length−(z+1));    ca.code = code2;    // Next, insertthe DUP instruction.    ca.code[z] = new byte[1];    ca.code[z][0] =(byte) 89;    // Finally, insert the INVOKESTATIC instruction.    if(exitindex == −1){     // This is the first time this class isencourtering the     // acquirelock instruction, so have to add it tothe     // constant pool.     cp_info[ ] cpi = newcp_info[cf.constant_pool.length+6];    System.arraycopy(cf.constant_pool, 0, cpi, 0,     cf.constant_pool.length);     cf.constant_pool = cpi;    cf.constant_pool_count += 6;     CONSTANT_Utf8_info u1 =      newCONSTANT_Utf8_info(“LockClient”);    cf.constant_pool[cf.constant_pool.length−6] = u1;    CONSTANT_Class_info c1 = new CONSTANT_Class_info(     cf.constant_pool_count−6);    cf.constant_pool[cf.constant_pool.length−5] = c1;     u1 = newCONSTANT_Utf8_info(“releaseLock”);    cf.constant_pool[cf.constant_pool.length−4] = u1;     u1 = newCONSTANT_Utf8_info(“(Ljava/lang/Object;)V”);    cf.constant_pool[cf.constant_pool.length−3] = u1;    CONSTANT_NameAndType_info n1 =      new CONSTANT_NameAndType_info(     cf.constant_pool.length−4, cf.constant_pool.length−3);    cf.constant_pool[cf.constant_pool.length−2] = n1;    CONSTANT_Methodref_info m1 = new CONSTANT_Methodref_info(     cf.constant_pool.length−5, cf.constant_pool.length−2);    cf.constant_pool[cf.constant_pool.length−1] = m1;     exitindex =cf.constant_pool.length−1;    }    ca.code[z+2] = new byte[3];   ca.code[z+2][0] = (byte) 184;    ca.code[z+2][1] = (byte)((exitindex >> 8) & 0xff);    ca.code[z+2][2] = (byte) (exitindex &0xff);    // And lastly, increase the CODE_LENGTH and ATTRIBUTE_LENGTH   // values.    ca.code_length += 4;    ca.attribute_length += 4;    z+= 1;      }     }     // If we changed this method, then increase thestack size by one.     if (changed){      ca.max_stack++;    // Just tomake sure.     }    }   }   try{    ByteArrayOutputStream out = newByteArrayOutputStream( );    cf.serialize(out);    byte[ ] b =out.toByteArray( );    return defineClass(name, b, 0, b.length);  }catch (Exception e){    throw new ClassNotFoundException(name);   } } }

1. A single computer intended to operate in a multiple computer systemwhich comprises a plurality of computers each having a local memory andeach being interconnected via a communications network, wherein adifferent portion of at least one application program each written toexecute on only a single computer executes substantially simultaneouslyon a corresponding one of said plurality of computers, and at least onememory location is replicated in the local memory of each said computer,said single computer comprising: a local memory having at least onememory location intended to be updated via said communications network,a communications port for connection to said communications network, andupdating means to transfer to said communications port any updatedcontent(s) of said replicated local memory location(s) whereby thecorresponding replicated memory location of each said computer of saidmultiple system can be updated via said communicating network and allsaid replicated memory locations can remain substantially identical. 2.The computer as claimed in claim 1 wherein each said replicated localmemory location is part of an independent local memory accessible onlyby the corresponding portion of said application program executing onsaid computer.
 3. The computer as claimed in claim 2 wherein said memorylocation includes at least one of an asset, object or resource and has avalue or content. 4-21. (canceled)
 22. A multiple computer system havingat least one application program each written to operate on only asingle computer but running simultaneously on a plurality of computersinterconnected by a communications network, wherein different portionsof said application program(s) execute substantially simultaneously ondifferent ones of said computers, wherein each computer has anindependent local memory accessible only by the corresponding portion ofsaid application program(s) and wherein for each said portion a likeplurality of substantially identical objects are created, each in thecorresponding computer.
 23. The system as claimed in claim 22 whereineach computer has an independent local memory accessible only by thecorresponding portion of said application program(s).
 24. The system asclaimed in claim 23 wherein each of said plurality of substantiallyidentical objects has a substantially identical name.
 25. The system asclaimed in claim 24 wherein each said computer includes a distributedrun time means with the distributed run time means of each said computerable to communicate with all other computers whereby if a portion ofsaid application program(s) running on one of said computers changes thecontents or value of an object in that computer then the change incontent or value for said object is propagated by the distributed runtime means of said one computer to all other computers to change thecontent or value of the corresponding object in each of said othercomputers.
 26. The system as claimed in claim 25 wherein each saidapplication program is modified before, during, or after loading byinserting an updating propagation routine to modify each instance atwhich said application program writes to memory, said updatingpropagation routine propagating every memory write by one computer tosaid other computers.
 27. The system as claimed in claim 26 wherein theapplication program is modified in accordance with a procedure selectedfrom the group of procedures consisting of re-compilation at loading,pre-compilation prior to loading, compilation prior to loading,just-in-time compilation, and re-compilation after loading and beforeexecution of the relevant portion of application program.
 28. The systemas claimed in claim 27 wherein said modified application program istransferred to all said computers in accordance with a procedureselected from the group consisting of master/slave transfer, branchedtransfer and cascaded transfer. 29-65. (canceled)
 66. A method ofrunning simultaneously on a plurality of computers at least oneapplication program each written to operate on only a single computer,said computers being interconnected by means of a communicationsnetwork, said method comprising the step of, (i) executing differentportions of said application program(s) on different ones of saidcomputers and for each said portion creating a like plurality ofsubstantially identical objects each in the corresponding computer andeach accessible only by the corresponding portion of said applicationprogram.
 67. The method as claimed in claim 66 wherein each computer hasan independent local memory which includes the corresponding identicalobject.
 68. The method as claimed in claim 66 comprising the furtherstep of, (i) naming each of said plurality of substantially identicalobjects with a substantially identical global name.
 69. The method asclaimed in claim 68 comprising the further step of, (i) if a portion ofsaid application program running on one of said computers changes thecontents or value of an object in that computer, then the change incontent or value of said object is propagated to all of the othercomputers via said communications network to change the content or valueof the corresponding object in each of said other computers.
 70. Themethod as claimed in claim 69 including the further step of: (i)modifying said application program before, during or after loading byinserting an updating propagation routine to modify each instance atwhich said application program writes to memory, said updatingpropagation routine propagating every memory write by one computer toall said other computers. 71-72. (canceled)
 73. A method of loading anapplication program written to operate only on a single computer ontoeach of a plurality of computers, the computers being interconnected viaa communications link, and different portions of said applicationprogram(s) being substantially simultaneously executable on differentcomputers with each computer having an independent local memoryaccessible only by the corresponding portion of said applicationprogram(s), the method comprising the step of modifying the applicationbefore, during, or after loading and before execution of the relevantportion of the application program.
 74. (canceled)
 75. The method asclaimed in claim 73 wherein said modifying step comprises:— (i)detecting instructions which share memory records utilizing one of saidcomputers, (ii) listing all such shared memory records and providing anaming tag for each listed memory record, (iii) detecting thoseinstructions which write to, or manipulate the contents of, any of saidlisted memory records, and (iv) generating an updating propagationroutine corresponding to each said detected write or manipulateinstruction, said updating propagation routine forwarding the re-writtenor manipulated contents and name tag of each said re-written ormanipulated listed memory record to all of the others of said computers.76-77. (canceled)
 78. A method of compiling or modifying an applicationprogram written to operate on only a single computer but to runsimultaneously on a plurality of computers interconnected via acommunications link, with different portions of said applicationprogram(s) executing substantially simultaneously on different ones ofsaid computers each of which has an independent local memory accessibleonly by the corresponding portion of said application program, saidmethod comprising the steps of: (i) detecting instructions which sharememory records utilizing one of said computers, (ii) listing all suchshared memory records and providing a naming tag for each listed memoryrecord, (iii) detecting those instructions which write to, or manipulatethe contents of, any of said listed memory records, and (iv) activatingan updating propagation routine following each said detected write ormanipulate instruction, said updating propagation routine forwarding there-written or manipulated contents and name tag of each said re-writtenor manipulated listed memory record to the remainder of said computers.79. The method as claimed in claim 78 and carried out prior to loadingthe application program onto each said computer, or during loading ofthe application program onto each said computer, or after loading of theapplication program onto each said computer and before execution of therelevant portion of the application program. 80-139. (canceled)
 140. Thecomputer as claimed in claim 1, further comprising: initialization meanswhich determine the initial content or value of said replicated memorylocation and which can be disabled.
 141. The computer as claimed inclaim 1, further comprising: finalization means which deletes saidreplicated memory location when all said computers no longer need torefer thereto, said finalization means being connected to saidcommunications port to receive therefrom data transmitted over saidnetwork relating to continued reference of other computers of saidmultiple computer system to said replicated memory location.
 142. Thecomputer as claimed in claim 1, further comprising: lock acquisition andrelinquishing means to respectively permit said replicated local memorylocation to be written to, and prevent said replicated local memorybeing written to, on command.
 143. The computer as claimed in claim 1,further comprising: initialization means which determine the initialcontent or value of said replicated memory location and which can bedisabled; finalization means which deletes said replicated memorylocation when all said computers no longer need to refer thereto, saidfinalization means being connected to said communications port toreceive therefrom data transmitted over said network relating tocontinued reference of other computers of said multiple computer systemto said replicated memory location; and lock acquisition andrelinquishing means to respectively permit said replicated local memorylocation to be written to, and prevent said replicated local memorybeing written to, on command.